From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 67D9B1391DB for ; Sun, 23 Mar 2014 20:27:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6B594E0BC4; Sun, 23 Mar 2014 20:27:49 +0000 (UTC) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by pigeon.gentoo.org (Postfix) with ESMTP id 7F56CE0BA0 for ; Sun, 23 Mar 2014 20:27:48 +0000 (UTC) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id h6is1n0060xGWP8558To9q; Sun, 23 Mar 2014 20:27:48 +0000 Received: from [192.168.1.13] ([50.190.84.14]) by omta12.westchester.pa.mail.comcast.net with comcast id h8Tn1n00l0JZ7Re3Y8Tok0; Sun, 23 Mar 2014 20:27:48 +0000 Message-ID: <532F43BF.7070405@gentoo.org> Date: Sun, 23 Mar 2014 16:27:43 -0400 From: Joshua Kinard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC GLEP 1005: Package Tags References: <20140323204428.58216f16@pomiot.lan> In-Reply-To: <20140323204428.58216f16@pomiot.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395606468; bh=X1vqd7ZpLMxwyZkIVa5B7XY/7UXJy+XL5xxeWjR0Ysk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eFeuA1d8c24WG0csOR3IdrPz5RSRK0W0WqCkk+F4Yp8TV2OeSNNuPfflt3/2V6eyL kEV3ngWwEGdiiZvSrzaq0ZAhkE9DOVj4Dt6pQzVkJpasgEkJcsVcMZumCMTKBDrX5y Q4rGAbfT6q8psixZWu2Z/LI754VEPKGBzeb/yZBlaXfKm/pNOtdzHubugnEn3uffov qAc4cIIFxRWAo5x3rUPrW5mWp50v29Uqr6VISlNXE7xhhbVmPnuqhGhQgA5Kb49dqy MTgefJr6TWZIlyMUOIJg69Oxe+1XLGZLMLwMim14rWXee5E6ZlplMoGVXOV2JaGT6v KcxohnqndvOMQ== X-Archives-Salt: 54efe370-6002-450d-9d66-5f65add821f7 X-Archives-Hash: 85baff5e6aaf11f12f9b22ca688273d0 On 03/23/2014 15:44, Michał Górny wrote: > Dnia 2014-03-22, o godz. 15:33:27 > Alec Warner napisał(a): > >> https://wiki.gentoo.org/wiki/Package_Tags >> >> Object or forever hold your peace. > > Honestly, I don't think metadata.xml is a good place for it. While I > like the consistency with general use of that file, I feel like it's > going to make the application of tags more cumbersome, more noisy > and make it harder to maintain consistency. > > As I see it, tags are not the same kind of package property > as the description or package name. As I see it, current metadata.xml > properties are somehow constant. They are usually set > by the maintainer, do not change often and are strictly related only to > the package. IMHO, metadata.xml is actually the best place to describe a package with tags, but I am not so sure it's the best place to "define" a tag. I guess if we automate the indexing of tags, much like how use.desc.local is generated from metadata.xml, then that might eliminate some of the maintenance overhead. The only way tags are going to work well is to keep the management of them as automated as possible. They should only be involved in searches for packages, and nothing else. E.g., hypothetical emerge command might be: emerge -T mail,client, which will show me all packages with the tag of 'mail' and 'client' (I didn't check emerge to see if -T already has a purpose, btw). And I think we should limit the number of tags allowed per package to a reasonable number. Maybe five tags maximum? StackOverflow is one example where they restrict questions to five tags. In addition, SO tries to suggest to you already-existing tags so that you reuse them instead of creating new ones all the time. Repoman could be extended to issue a warning when metadata.xml contains previously undefined tags and optionally display a match of similarly-named, existing tags (if only to catch misspellings, 'mial' or 'cleint' instead of 'mail' and 'client'). > Tags, on the other hand, are more 'live'. They place the package > somewhere in the 'global' tag hierarchy that can change over time. > I expect that people other than maintainers will be adding tags to > packages (and changing them), and that people will invent new tags > and apply them to more packages. > > So, first of all, your solution would mean that every commit adding > a new tag or changing one of the tags would modify the package > metadata.xml. This means a Manifest update and a ChangeLog entry (please > don't get into more rules for ChangeLogs now), and this means it will be > harder to find actually useful entries there. > > So we make tag updates harder, and increase time and size of rsync. Instead of individual lines in metadata.xml for each tag, why not a single line that contains a comma-delimited list of up to five tags, whitespace optional? That should help reduce the "fluff" of the tree by adding this feature. E.g., one,two,three,four,five vs. one two three four five (36 bytes vs. 82 bytes) > Secondly, since tags for every package will be held in different files, > people will need dedicated tools to collect tags from all those files > and add matching tags to their own packages. Long story short, we're > going to have many 'duplicate' tags that will require even more commits > with ChangeLog entries and Manifest updates. If we automate the generation of a master tag index file, like use.desc.local, this can be avoided. emerge can simply go rummage through the master index for matching tag entries instead of going through the entire tree. Because if we wanted to sift through the entire tree, grep would be a far better method (compiled C and probably better text-matching algorithms than emerge). > Worse than that, your GLEP doesn't even have any basic rules for naming > tags -- like what language form to use and, say, which character to use > instead of space. This sounds like the sort of things that's going to > make it even harder to get some consistency, especially if some > developers are going to follow someone else committing earlier and some > will follow their own rules. Easy: ASCII, alphanumeric only, must start with a letter, lowercase, no spaces. A lot of problems are avoided if we keep tags to one-word descriptors only. E.g., for mail clients, they would carry both 'mail' and 'client' as two of their five tags. For kmail, a third tag would be 'kde' and Evolution would have 'gnome' instead. > I'd honestly prefer that -- if we should really keep tags in the tree > -- to do that with a single 'metadata/tags' file or some kind of > hierarchy there. Keep them outside the package directory -- bind > packages to tags, rather than tags to packages. Keep all the commits > in a single place without altering the ebuild work flow. While I definitely like the idea of a single, master file, I feel this could run away pretty quickly as it's continuously updated. For example, adding a new package, a dev has to now remember to add the new package's relevant tags to this file, and remove its entry when that package is removed from the tree. By auto-generating this file from metadata.xml contents, tag management is more evenly distributed to individual package maintainers, who just have to remember to add the relevant entries to metadata.xml for their package's tags to get indexed, and when a package is removed, its tags will also be removed. I'd also suggest that 'all' be considered a default, global tag for all packages, it be a reserved tag internal to emerge and other package managers, and not count against the number of allowed tags (meaning that technically, a package is allow five tags + 'all'). As for default tags when a package does not define any, the package category gets split at the hyphen and becomes two independent tags. This is overridden when at least one tag is defined in metadata.xml. -- Joshua Kinard Gentoo/MIPS kumba@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic