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 |