Re: [gentoo-dev] RFC GLEP 1005: Package Tags

[Joshua Kinard]

On 03/23/2014 15:44, Micha³ Górny wrote:
> Dnia 2014-03-22, o godz. 15:33:27
> Alec Warner <antarus@g.o> 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
kumba@g.o
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