On Thu, 2012-09-13 at 03:39 -0700, Brian Harring wrote:
> Hola.
>
> CC'ing pms since obviously they should comment, although the
> discussion should be on -dev (aka, public, not an alias).
>
> Sorry, this is a long email; condensing it down into a glep is viable,
> just my time is limited (it's telling I started the gentoo stuff at
> 2am, wrapping up likely at 4am).
>
> The length of this email basically relates to the subtlety of this
> proposal; at first glance it may appear as if I'm proposing a syntax
> shuffle just for aesthetic reasons, but as elaborated in the tail end,
> that subtle syntax change opens up a lot of possibilities.
>
>
> Either way, what I propose, is pretty simple. Currently USE_EXPAND'd
> groups are pushed into USE in the form ${use_group}_${setting}.
>
> Thus VIDEO_CARDS="intel nvidia" becomes video_cards_intel
> video_cards_nvidia. This should be reasonably well known and
> understood from the dev standpoint; from the PM side of things, this
> actually seriously sucks ass; if we see video_cards_intel in an IUSE
> somewhere, we don't know if it's a USE flag, or a use_expanded group;
> to figure that out, we basically have to do a longest prefix matching
> (or suffix tree).
>
> There in is one of the subtle design flaws of it; two USE_EXPAND'd
> targets, VIDEO_CARDS and VIDEO, can intersect in their namespace.
> While we (devs) intentionally avoid this potential via careful name
> choice, the fact the possibility exists is a bit of a sign that
> USE_EXPAND was a bit of a hack.
>
> What I propose is simple enough, and is for >=EAPI5:
>
> 1) We disallow '@' in USE flags (yes, a use flag can actually have
> '@' in it's name according to PMS; someone was hitting the crack
> pipe pretty damn hard when they allowed that one). This doesn't
> impact anything in gentoo-x86, nor any tree I've ever seen.
>
> 2) If <EAPI5, we continue exporting video_cards_nvidia
> (${use_group}_${setting}).
>
> 3) If >=EAPI5, we export ${use_group}_${setting}, *and*
> ${use_group}@${setting}. While there may be complaints about having
> it exported in two fashions, the reason for this is simple- it makaes
> transition way the fuck easier, meaning we don't make devs wrie pain
> in the ass "if eapi x, else blah" code. Basically, for eclass code,
> the dev would do thus:
> 3.a) If the eclass supports <EAPI5, they check for the old form;
> ${use_group}_${setting}.
> 3.b) If however that eclass is >=EAPI5, they should check for the new
> form; ${use_group}@{setting}.
>
> 4) At some point in the future, when either code involved has migrated
> all to EAPI5, or we do something in a later EAPI that renders
> supporting ${use_group}_${setting} untenuable, we stop exporting
> ${use_group}_${setting} for those EAPIs. Preferably with one EAPI
> cycle w/ deprecation warnings.
>
...
> ~harring
> +1 This would make things easier for PM consumer apps to process use flags without specialized code to figure out if the flag was use_expanded or just had an "_" in it's name... -- Brian Dolbec <dol...@gentoo.org>
signature.asc
Description: This is a digitally signed message part
