On Wed, Jun 22, 2011 at 14:19, Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > On Wed, 22 Jun 2011 21:55:18 +1200 > Kent Fredric <kentfred...@gmail.com> wrote: >> I'd love a tag solution, that'd be nice, is there a GLEP for it yet? >> And if so, how long will it take to get this "tag" feature supported >> by EAPI standards? > > The slow parts are coming up with a good design, getting the Council to > approve it, and getting Portage to implement it. The fast part is > getting the PMS bit done. > > The problem with tags is that all we've heard so far is "we should have > tags!", with no description of what tags are, what they'll solve or how > they're used. > > -- > Ciaran McCreesh >
Tags are basically keywords you can use to describe packages, allowing you to easily search and explore your options based on what the packages actually does (if we want to get technical, anything that identifies a package is a sort of tag: name, version, license, set, checksum, etc.). It's just a vocabulary that eases the burden of human lookup. The categories we have now are essentially (pairs of) tags tied to a treelike structure in an actual filesystem, and I'd wager that's a decent place to start, too-- probably the most prominent problem I can see with the current method comes from these edge cases where one category is obviously not enough. The obvious solution is probably to just stick our semantic metadata into the metadata.xml. So for...say, media-video/kdenlive, <cat>media-video</cat>[1] becomes more like this: <cat> <tag>media</tag> <tag>video</tag> <tag>kde</tag> <tag>editors</tag> </cat> The canonical tag list needn't even expand beyond what we have already (for the time being; attempting to keep your vocabulary entirely static is a Bad Thing. Humans are amazing at finding new things that need tagging. Getting ahead of myself, though). In the practical sense, we can probably just whip out a quick script and get 98% coverage; package maintainers should be encouraged to add relevant tags to the packages under their care as needed. --Wyatt, hoping this text is plain as it says it is. Sorry if it's not. [1] Let's just assume for the sake of argument that kdenlive actually has a <cat> field in its metadata file.
