1 |
Dnia 2014-03-23, o godz. 17:40:20 |
2 |
Joshua Kinard <kumba@g.o> napisał(a): |
3 |
|
4 |
> On 03/23/2014 17:05, Michał Górny wrote: |
5 |
> > Dnia 2014-03-23, o godz. 16:27:43 |
6 |
> > Joshua Kinard <kumba@g.o> napisał(a): |
7 |
> > |
8 |
> >> On 03/23/2014 15:44, Michał Górny wrote: |
9 |
> >>> Tags, on the other hand, are more 'live'. They place the package |
10 |
> >>> somewhere in the 'global' tag hierarchy that can change over time. |
11 |
> >>> I expect that people other than maintainers will be adding tags to |
12 |
> >>> packages (and changing them), and that people will invent new tags |
13 |
> >>> and apply them to more packages. |
14 |
> >>> |
15 |
> >>> So, first of all, your solution would mean that every commit adding |
16 |
> >>> a new tag or changing one of the tags would modify the package |
17 |
> >>> metadata.xml. This means a Manifest update and a ChangeLog entry (please |
18 |
> >>> don't get into more rules for ChangeLogs now), and this means it will be |
19 |
> >>> harder to find actually useful entries there. |
20 |
> >>> |
21 |
> >>> So we make tag updates harder, and increase time and size of rsync. |
22 |
> >> |
23 |
> >> Instead of individual <tag> lines in metadata.xml for each tag, why not a |
24 |
> >> single <tags> line that contains a comma-delimited list of up to five tags, |
25 |
> >> whitespace optional? That should help reduce the "fluff" of the tree by |
26 |
> >> adding this feature. |
27 |
> >> |
28 |
> >> E.g., |
29 |
> >> |
30 |
> >> <tags>one,two,three,four,five</tags> |
31 |
> > |
32 |
> > Either use XML, or don't use XML. Don't make this some kind of ugly |
33 |
> > mixture of XML with non-XML. |
34 |
> > |
35 |
> > So: |
36 |
> > |
37 |
> > <tags> |
38 |
> > <tag>one</tag> |
39 |
> > <tag>two</tag> |
40 |
> > </tags> |
41 |
> > |
42 |
> > if we're really going for this. But I guess our DTD doesn't allow easy |
43 |
> > definition of single <tags/> with no forced position. |
44 |
> |
45 |
> TBH, I don't like the use of XML at all. Never have and never will. I am a |
46 |
> big fan of INI-style definitions (i.e., like Samba's config). XML just |
47 |
> leads to a lot of unneeded fluff in what should be a really small file, |
48 |
> which is why I was proposing a single <tags> element instead of multiple |
49 |
> <tag> elements. |
50 |
|
51 |
metadata.xml is XML at the moment, so you are supposed to obey its |
52 |
rules, whether you like them or not. if you want to replace it with |
53 |
something else, feel free to try. But don't make a shitsoup mixin out |
54 |
of it. |
55 |
|
56 |
> >>> Secondly, since tags for every package will be held in different files, |
57 |
> >>> people will need dedicated tools to collect tags from all those files |
58 |
> >>> and add matching tags to their own packages. Long story short, we're |
59 |
> >>> going to have many 'duplicate' tags that will require even more commits |
60 |
> >>> with ChangeLog entries and Manifest updates. |
61 |
> >> |
62 |
> >> If we automate the generation of a master tag index file, like |
63 |
> >> use.desc.local, this can be avoided. emerge can simply go rummage through |
64 |
> >> the master index for matching tag entries instead of going through the |
65 |
> >> entire tree. Because if we wanted to sift through the entire tree, grep |
66 |
> >> would be a far better method (compiled C and probably better text-matching |
67 |
> >> algorithms than emerge). |
68 |
> > |
69 |
> > And this goes pretty much backwards to what we were aiming at. We |
70 |
> > should finally kill use.desc.local, not get inspired by the redundancy. |
71 |
> |
72 |
> And what replaces it? What differentiates a global USE flag that has |
73 |
> purpose across multiple packages (like 'ipv6') against a flag that only |
74 |
> exists for a single package? |
75 |
|
76 |
Applications are supposed to read metadata.xml for local flags. That's |
77 |
all about it. Having an extra index file doesn't really make sense |
78 |
there. |
79 |
|
80 |
> >>> Worse than that, your GLEP doesn't even have any basic rules for naming |
81 |
> >>> tags -- like what language form to use and, say, which character to use |
82 |
> >>> instead of space. This sounds like the sort of things that's going to |
83 |
> >>> make it even harder to get some consistency, especially if some |
84 |
> >>> developers are going to follow someone else committing earlier and some |
85 |
> >>> will follow their own rules. |
86 |
> >> |
87 |
> >> Easy: ASCII, alphanumeric only, must start with a letter, lowercase, no |
88 |
> >> spaces. A lot of problems are avoided if we keep tags to one-word |
89 |
> >> descriptors only. E.g., for mail clients, they would carry both 'mail' and |
90 |
> >> 'client' as two of their five tags. For kmail, a third tag would be 'kde' |
91 |
> >> and Evolution would have 'gnome' instead. |
92 |
> > |
93 |
> > I'm pretty sure you will finally hit something that goes with two |
94 |
> > words. Protocol name or something. |
95 |
> |
96 |
> Perhaps, but we can fight that battle when we get there. starting off with |
97 |
> one-word tags keeps things simple for now and that'll make it easier to |
98 |
> determine whether this experiment actually pans out or not. |
99 |
|
100 |
If you introduce arbitrary limitations, people will either find a way |
101 |
around them (which means getting even worse mess) or omit some tags. |
102 |
Either way, tags become less helpful. |
103 |
|
104 |
> >> I'd also suggest that 'all' be considered a default, global tag for all |
105 |
> >> packages, it be a reserved tag internal to emerge and other package |
106 |
> >> managers, and not count against the number of allowed tags (meaning that |
107 |
> >> technically, a package is allow five tags + 'all'). |
108 |
> >> |
109 |
> >> As for default tags when a package does not define any, the package category |
110 |
> >> gets split at the hyphen and becomes two independent tags. This is |
111 |
> >> overridden when at least one tag is defined in metadata.xml. |
112 |
> > |
113 |
> > Will this have a real benefit? Sounds like unnecessary confusion for |
114 |
> > a minor gain to me. |
115 |
> |
116 |
> Which? The internal 'all' tag or the use of existing category names as a |
117 |
> default set of tags for packages that don't have any tags defined? |
118 |
|
119 |
The 'all' tag sounds like something that would have no value. |
120 |
|
121 |
The automagic tags sound like a way to confuse people -- yesterday it |
122 |
had this tag, now I wanted to add a new one and the old tag |
123 |
disappeared! Not to mention sometimes the categories don't give really |
124 |
useful tags. Tags are not replacing categories, so no point in trying |
125 |
to bind the two together. |
126 |
|
127 |
-- |
128 |
Best regards, |
129 |
Michał Górny |