Dnia 2014-03-23, o godz. 16:27:43 Joshua Kinard <ku...@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
signature.asc
Description: PGP signature
