Dnia 2014-03-23, o godz. 16:27:43
Joshua Kinard <kumba@gentoo.org> napisał(a):

> On 03/23/2014 15:44, Michał Górny wrote:
> > 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>

Either use XML, or don't use XML. Don't make this some kind of ugly
mixture of XML with non-XML.

So:

  <tags>
    <tag>one</tag>
    <tag>two</tag>
  </tags>

if we're really going for this. But I guess our DTD doesn't allow easy
definition of single <tags/> with no forced position.

> > 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).

And this goes pretty much backwards to what we were aiming at. We
should finally kill use.desc.local, not get inspired by the redundancy.

> > 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'm pretty sure you will finally hit something that goes with two
words. Protocol name or something.

> 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.

Will this have a real benefit? Sounds like unnecessary confusion for
a minor gain to me.

-- 
Best regards,
Michał Górny