Doug Goldstein wrote:
> Marius Mauch wrote:
>> On Thu, 05 Jun 2008 17:01:00 -0400
>> Doug Goldstein <cardoe@g.o> wrote:
>>
>>  
>>> Marius Mauch wrote:
>>>    
>>>> On Thu, 05 Jun 2008 15:42:24 -0400
>>>> Doug Goldstein <cardoe@g.o> wrote:
>>>>
>>>>        
>>>>> All,
>>>>>
>>>>> Here's a GLEP for the addition of USE flag descriptions to package 
>>>>> metadata. It does not address any future ideas that others may have
>>>>> had or suggested. It merely gives developers the necessary "tools"
>>>>> to document their USE flag usage it better detail on a per package
>>>>> basis.
>>>>>
>>>>> An clearly motivation explanation that I didn't add, which I'm
>>>>> going to add once I send this is the fact that as per the QA
>>>>> Project, use.local.desc can not contain a USE flag that already
>>>>> appears globally in use.desc. This would allow a description for
>>>>> that USE flag to be contained in the metadata.
>>>>>
>>>>> http://www.gentoo.org/proj/en/glep/glep-0056.html
>>>>>
>>>>> I encourage any and all _technical_ feedback.
>>>>>             
>>>> Doesn't include any statement about compability with existing tools
>>>> or how it's related to use.local.desc (replacement, extension, ...)
>>>>
>>>> Marius
>>>>         
>>> It purposefully does not. XML is an extensible language that allows
>>> for this type of expandability. Current tools should be able to
>>> validate that adding these tags are valid if they appear in the DTD.
>>> However, if those tools do not handle those tags they should not do
>>> anything with them, hence the nature of XML.
>>>     
>>
>> I was more talking about tools that process use flag information
>> (equery, euse, ufed, ...).
>>
>>  
>>> The replacement of use.local.desc would necessitate a change to any
>>> and all tools which use that file and require them to support the new
>>> XML data. This of course introduces a chicken/egg issue. I have
>>> mentioned to infra the possibility of having a pre-rsync process that
>>> condensed all metadata.xml's into a use.local.desc that would be part
>>> of rsync data but not part of CVS. This could be written as a CVS
>>> hook to see when a metadata.xml was touched and run the utility
>>> appropriately.
>>>
>>> But again, this is outside the scope of this GLEP, whose purpose
>>> merely is to provide a way to document this.
>>>     
>>
>> I disagree. At the very least state that the GLEP does not replace
>> use.local.desc if that's the intention, and which location is
>> supposed to take priority if a flag is defined in both. Otherwise
>> different tools will use different rules and generating inconsistent
>> results. And there are many tools affected by this ...
>>
>> Marius
>>
>> PS: I like the general idea, but as long as compability issues are
>> completely ignored by the GLEP I have to oppose it.
>>   
> Considering Portage and repoman currently require any and all USE 
> flags appearing in IUSE to be present in use.local.desc, there should 
> be no ambiguity to the compatibility issues currently. I 100% expect 
> different tools to provide different results. Writing a GLEP stating 
> that one file is preferred over another will not cause those tools to 
> magically choose. The tools and their maintainers should be pushed by 
> the community to use the best data available. If use.local.desc 
> provides this data, then so be it. The initial goal of this GLEP is 
> really to allow per-package descriptions of global USE flags [*]. 
> There by different tools will provide more detailed information about 
> USE flags and some will simply not. That will result in a community 
> push to make these tools use newer data available and as such will 
> result in one day use.local.desc becoming deprecated. But, we're 
> speaking about something which may never happen. Or may happen in 
> another GLEP in the future.
>
> [*] As decided by the Gentoo QA Team, any USE flag that appears in 
> use.desc CAN NOT appear in use.local.desc. There by, there is no way 
> for a descriptive variation of a global USE flag to officially appear 
> in any medium.
Replying to myself is evil, but I'm going to try to clarify a bit more. 
GLEPs are more like RFCs. We can't force any application to do anything 
with a GLEP. We technically can't even force Portage to do anything in a 
GLEP since there's nothing that states Portage is the official package 
manager of Gentoo Linux and must follow all GLEPs. I personally feel any 
GLEP that tries to force any action to be taken by application 
developers and does not include a reference implementation or patches 
for said application(s), is fundamentally flawed (this is something I 
look to address in the future.

For example, take RFC 3514 [1], it might be great on paper if you could 
have everyone follow it. However, go ahead and try to actually force 
every single developer out there to implement it. Similar situation. A 
GLEP being approved isn't going to make truedfx suddenly hop up and 
update ufed to support these new descriptions because a) what's forcing 
him? it's open source. There's no corporate overlord threatening to fire 
him if he doesn't.  b) it's pretty worthless initially since there won't 
be any content for it to consume.

[1] http://www.faqs.org/rfcs/rfc3514.html

-- 
gentoo-dev@g.o mailing list