1 |
Doug Goldstein wrote: |
2 |
> Marius Mauch wrote: |
3 |
>> On Thu, 05 Jun 2008 17:01:00 -0400 |
4 |
>> Doug Goldstein <cardoe@g.o> wrote: |
5 |
>> |
6 |
>> |
7 |
>>> Marius Mauch wrote: |
8 |
>>> |
9 |
>>>> On Thu, 05 Jun 2008 15:42:24 -0400 |
10 |
>>>> Doug Goldstein <cardoe@g.o> wrote: |
11 |
>>>> |
12 |
>>>> |
13 |
>>>>> All, |
14 |
>>>>> |
15 |
>>>>> Here's a GLEP for the addition of USE flag descriptions to package |
16 |
>>>>> metadata. It does not address any future ideas that others may have |
17 |
>>>>> had or suggested. It merely gives developers the necessary "tools" |
18 |
>>>>> to document their USE flag usage it better detail on a per package |
19 |
>>>>> basis. |
20 |
>>>>> |
21 |
>>>>> An clearly motivation explanation that I didn't add, which I'm |
22 |
>>>>> going to add once I send this is the fact that as per the QA |
23 |
>>>>> Project, use.local.desc can not contain a USE flag that already |
24 |
>>>>> appears globally in use.desc. This would allow a description for |
25 |
>>>>> that USE flag to be contained in the metadata. |
26 |
>>>>> |
27 |
>>>>> http://www.gentoo.org/proj/en/glep/glep-0056.html |
28 |
>>>>> |
29 |
>>>>> I encourage any and all _technical_ feedback. |
30 |
>>>>> |
31 |
>>>> Doesn't include any statement about compability with existing tools |
32 |
>>>> or how it's related to use.local.desc (replacement, extension, ...) |
33 |
>>>> |
34 |
>>>> Marius |
35 |
>>>> |
36 |
>>> It purposefully does not. XML is an extensible language that allows |
37 |
>>> for this type of expandability. Current tools should be able to |
38 |
>>> validate that adding these tags are valid if they appear in the DTD. |
39 |
>>> However, if those tools do not handle those tags they should not do |
40 |
>>> anything with them, hence the nature of XML. |
41 |
>>> |
42 |
>> |
43 |
>> I was more talking about tools that process use flag information |
44 |
>> (equery, euse, ufed, ...). |
45 |
>> |
46 |
>> |
47 |
>>> The replacement of use.local.desc would necessitate a change to any |
48 |
>>> and all tools which use that file and require them to support the new |
49 |
>>> XML data. This of course introduces a chicken/egg issue. I have |
50 |
>>> mentioned to infra the possibility of having a pre-rsync process that |
51 |
>>> condensed all metadata.xml's into a use.local.desc that would be part |
52 |
>>> of rsync data but not part of CVS. This could be written as a CVS |
53 |
>>> hook to see when a metadata.xml was touched and run the utility |
54 |
>>> appropriately. |
55 |
>>> |
56 |
>>> But again, this is outside the scope of this GLEP, whose purpose |
57 |
>>> merely is to provide a way to document this. |
58 |
>>> |
59 |
>> |
60 |
>> I disagree. At the very least state that the GLEP does not replace |
61 |
>> use.local.desc if that's the intention, and which location is |
62 |
>> supposed to take priority if a flag is defined in both. Otherwise |
63 |
>> different tools will use different rules and generating inconsistent |
64 |
>> results. And there are many tools affected by this ... |
65 |
>> |
66 |
>> Marius |
67 |
>> |
68 |
>> PS: I like the general idea, but as long as compability issues are |
69 |
>> completely ignored by the GLEP I have to oppose it. |
70 |
>> |
71 |
> Considering Portage and repoman currently require any and all USE |
72 |
> flags appearing in IUSE to be present in use.local.desc, there should |
73 |
> be no ambiguity to the compatibility issues currently. I 100% expect |
74 |
> different tools to provide different results. Writing a GLEP stating |
75 |
> that one file is preferred over another will not cause those tools to |
76 |
> magically choose. The tools and their maintainers should be pushed by |
77 |
> the community to use the best data available. If use.local.desc |
78 |
> provides this data, then so be it. The initial goal of this GLEP is |
79 |
> really to allow per-package descriptions of global USE flags [*]. |
80 |
> There by different tools will provide more detailed information about |
81 |
> USE flags and some will simply not. That will result in a community |
82 |
> push to make these tools use newer data available and as such will |
83 |
> result in one day use.local.desc becoming deprecated. But, we're |
84 |
> speaking about something which may never happen. Or may happen in |
85 |
> another GLEP in the future. |
86 |
> |
87 |
> [*] As decided by the Gentoo QA Team, any USE flag that appears in |
88 |
> use.desc CAN NOT appear in use.local.desc. There by, there is no way |
89 |
> for a descriptive variation of a global USE flag to officially appear |
90 |
> in any medium. |
91 |
Replying to myself is evil, but I'm going to try to clarify a bit more. |
92 |
GLEPs are more like RFCs. We can't force any application to do anything |
93 |
with a GLEP. We technically can't even force Portage to do anything in a |
94 |
GLEP since there's nothing that states Portage is the official package |
95 |
manager of Gentoo Linux and must follow all GLEPs. I personally feel any |
96 |
GLEP that tries to force any action to be taken by application |
97 |
developers and does not include a reference implementation or patches |
98 |
for said application(s), is fundamentally flawed (this is something I |
99 |
look to address in the future. |
100 |
|
101 |
For example, take RFC 3514 [1], it might be great on paper if you could |
102 |
have everyone follow it. However, go ahead and try to actually force |
103 |
every single developer out there to implement it. Similar situation. A |
104 |
GLEP being approved isn't going to make truedfx suddenly hop up and |
105 |
update ufed to support these new descriptions because a) what's forcing |
106 |
him? it's open source. There's no corporate overlord threatening to fire |
107 |
him if he doesn't. b) it's pretty worthless initially since there won't |
108 |
be any content for it to consume. |
109 |
|
110 |
[1] http://www.faqs.org/rfcs/rfc3514.html |
111 |
|
112 |
-- |
113 |
gentoo-dev@l.g.o mailing list |