On 03/23/2014 15:44, Michał Górny wrote: > Dnia 2014-03-22, o godz. 15:33:27 > Alec Warner <anta...@gentoo.org> 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 <tag> lines in metadata.xml for each tag, why not a single <tags> 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., <tags>one,two,three,four,five</tags> vs. <tag>one</tag> <tag>two</tag> <tag>three</tag> <tag>four</tag> <tag>five</tag> (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 ku...@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
