Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: kumba@g.o
Subject: Re: [gentoo-dev] RFC GLEP 1005: Package Tags
Date: Sun, 23 Mar 2014 21:05:44
Message-Id: 20140323220515.22bcced5@pomiot.lan
In Reply to: Re: [gentoo-dev] RFC GLEP 1005: Package Tags by Joshua Kinard
1 Dnia 2014-03-23, o godz. 16:27:43
2 Joshua Kinard <kumba@g.o> napisał(a):
3
4 > On 03/23/2014 15:44, Michał Górny wrote:
5 > > Tags, on the other hand, are more 'live'. They place the package
6 > > somewhere in the 'global' tag hierarchy that can change over time.
7 > > I expect that people other than maintainers will be adding tags to
8 > > packages (and changing them), and that people will invent new tags
9 > > and apply them to more packages.
10 > >
11 > > So, first of all, your solution would mean that every commit adding
12 > > a new tag or changing one of the tags would modify the package
13 > > metadata.xml. This means a Manifest update and a ChangeLog entry (please
14 > > don't get into more rules for ChangeLogs now), and this means it will be
15 > > harder to find actually useful entries there.
16 > >
17 > > So we make tag updates harder, and increase time and size of rsync.
18 >
19 > Instead of individual <tag> lines in metadata.xml for each tag, why not a
20 > single <tags> line that contains a comma-delimited list of up to five tags,
21 > whitespace optional? That should help reduce the "fluff" of the tree by
22 > adding this feature.
23 >
24 > E.g.,
25 >
26 > <tags>one,two,three,four,five</tags>
27
28 Either use XML, or don't use XML. Don't make this some kind of ugly
29 mixture of XML with non-XML.
30
31 So:
32
33 <tags>
34 <tag>one</tag>
35 <tag>two</tag>
36 </tags>
37
38 if we're really going for this. But I guess our DTD doesn't allow easy
39 definition of single <tags/> with no forced position.
40
41 > > Secondly, since tags for every package will be held in different files,
42 > > people will need dedicated tools to collect tags from all those files
43 > > and add matching tags to their own packages. Long story short, we're
44 > > going to have many 'duplicate' tags that will require even more commits
45 > > with ChangeLog entries and Manifest updates.
46 >
47 > If we automate the generation of a master tag index file, like
48 > use.desc.local, this can be avoided. emerge can simply go rummage through
49 > the master index for matching tag entries instead of going through the
50 > entire tree. Because if we wanted to sift through the entire tree, grep
51 > would be a far better method (compiled C and probably better text-matching
52 > algorithms than emerge).
53
54 And this goes pretty much backwards to what we were aiming at. We
55 should finally kill use.desc.local, not get inspired by the redundancy.
56
57 > > Worse than that, your GLEP doesn't even have any basic rules for naming
58 > > tags -- like what language form to use and, say, which character to use
59 > > instead of space. This sounds like the sort of things that's going to
60 > > make it even harder to get some consistency, especially if some
61 > > developers are going to follow someone else committing earlier and some
62 > > will follow their own rules.
63 >
64 > Easy: ASCII, alphanumeric only, must start with a letter, lowercase, no
65 > spaces. A lot of problems are avoided if we keep tags to one-word
66 > descriptors only. E.g., for mail clients, they would carry both 'mail' and
67 > 'client' as two of their five tags. For kmail, a third tag would be 'kde'
68 > and Evolution would have 'gnome' instead.
69
70 I'm pretty sure you will finally hit something that goes with two
71 words. Protocol name or something.
72
73 > I'd also suggest that 'all' be considered a default, global tag for all
74 > packages, it be a reserved tag internal to emerge and other package
75 > managers, and not count against the number of allowed tags (meaning that
76 > technically, a package is allow five tags + 'all').
77 >
78 > As for default tags when a package does not define any, the package category
79 > gets split at the hyphen and becomes two independent tags. This is
80 > overridden when at least one tag is defined in metadata.xml.
81
82 Will this have a real benefit? Sounds like unnecessary confusion for
83 a minor gain to me.
84
85 --
86 Best regards,
87 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] RFC GLEP 1005: Package Tags Joshua Kinard <kumba@g.o>