Note I inadvertantly cross posted, I was intending on cc'ing
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
> 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
> 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.