Note I inadvertantly cross posted, I was intending on cc'ing 
council@g.o.

As such one final cc to that ml to end this subthread while pulling 
this back to -dev.


On Wed, Mar 31, 2010 at 11:16:22PM +1300, Alistair Bush wrote:
> > Hola all-
> >  
> > Comments desired; assuming no significant blowback, I'll be pushing
> > this to the council level since eapi4 is annoying feature locked right
> 
> I think this solution is far better,  until someone smarter than me tells me 
> otherwise.
> 
> Don't know whether I like the VALID_USE var name,  so please at least think 
> about something a little better if you can ;).  ( I like green,  but not too 
> green if you know what I mean )
>
> Will we still have to define the use flags in IUSE?

Yes, although if folks have a better proposal that incorporates 
VALID_USE into IUSE I'm definitely open to it- the original proposal 
for VALID_USE tried to inline it into IUSE, but it got ugly (hence it 
mutating it this form).

The problem w/ trying to reuse IUSE is the following (sorry, I like 
lists of assertions)-

*) IUSE currently serves as a list of valid USE flags, just that.  No 
repeat specification of a flag (which means the dev in question is 
unlikely to typo a flag).

*) having a single specified list of valid use flags is the basis for 
doing validation of use flags used in all other metadata.  In other 
words, that list of valid use flags *really* needs to go out of it's 
way to make human error hard.

*) VALID_USE is a set of assertions on the allowed state of USE; IUSE 
is just a list of flags.  Intermixing the two in a way that is still 
readable is really ugly

*) given a library that has optional perl and python bindings 
(which can be toggled freely, they're standalone flags) I've nfc how 
one would sanely specify that w/in IUSE while adding VALID_USE 
semantics.  Possibly, you could include use conditionals into IUSE, 
and treat the () contents as assertions- but that makes adding xor in 
hard, is rather ugly/hard on the eyes, and violates the DRY (Don't 
Repeat Yourself) principle from above.

Definitely open to counterproposals that address those 
concerns however...


> I'm guessing we can't use IUSE to store this information because of the  whole 
> glep-55 thing.

glep-55 is unrelated to this as far as I can tell- if you think 
otherwise please clarify.

Thanks
~harring