[gentoo-dev] USE_EXPAND / USE 'configuration space' refactoring.

[Brian Harring]

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.

Basically, this approach is zero impact for devs for the most part; 
you don't have to do multiple paths for checking use wise if 
supporting EAPI5 in parallel to others.  Once your code is EAPI5 (and 
above), you use the new syntax- or worst case, someone interested goes 
and converts your >=EAPI5 ebuild/eclass to use the new syntax on your 
behalf.

Thus far, I've not particularly sold this notion in this email- I 
focused on making damn clear this cleanup is basically no cost for 
everyone but PM authors (and it's easy enough for us to handle).

Aside from the cleanup/sanity improvements to our algos for 
backmatching USE_EXPAND groups, this syntax gets us actually some 
rathre nifty shit; it basically allows us to introduce a generation 
configuration space.

So... onto examples of why we should do this beyond the basic "it's a 
cleaner syntax/design" argument:

--Per phase RESTRICT usage--
Exactly as it sounds.  Consider userpriv- most of the time that's 
turned off, that's purely because one phase- literally just one 
phase- needs to do something via root.  Thus we weaken the entirety 
of the protection.  Now, we could do some bastardly shit w/ existing 
use_expand for this (which has some conflict potentials for the PM), 
or via this syntax, we could do:

RESTRICT="phase@src_install? ( userpriv )"

Now, not all restricts are phase level- fetch, strip, installsources, 
etc, operate on a global level.  userpriv, usersandbox, sandbox 
(latter two aren't used in gentoo-x86, although PM's support it still) 
are phase specific.  That may seem like a small list, but consider 
that

1) pkgcore has fakeroot code; it's had it for a while, I'm intending 
on resurrecting that; this requires a RESTRICT='fakeroot' however.
2) I intend to start abusing the 'unshare' utility (man 1 unshare) to 
contain ebuilds build process; basically gives us a way to level some 
protections for the build host.  I'd be very surprised if other PM's 
don't follow suit (or do it before I do even); it's a simple 
protection that's worth doing.
3) There's been repeated talk of using containers/overlays to 
constrain the build process; sooner or later someones going to do it, 
and you can be damn sure a restrict will be necessary.

Etc, you get the idea; the point of the new syntax is general 
flexibility and allowing us to be finegrained in RESTRICT where 
useful.


--A form of unified DEPENDENCIES that fits into our existing style--

First, I'd appreciate it if the frothing over DEPENDENCIES wasn't 
involved here; this syntax lends itself to DEPENDENCIES, the debate 
about whether or not to do DEPENDENCIES is orthogonal.

Either way, we could do thus:

DEPENDENCIES="
dep@build,run? ( common deps/rdeps )
dep@run? ( rdep specific )"

Etc.  There's a subtly there; specifically that it's a 
conditional w/ multiple settings being checked.  Now, we could either 
do that as per USE_GROUP (moreso, per conditional namespace- dep being 
a namespace, just like 'phase' was one from earlier) rules, which I 
think sucks, or we could come up with common syntax there, which leads 
into the next potential feature we can build via this:

-- Reducing duplication, and avoiding multi-slot issues --

Picking on mesa, the following deps:

>=x11-libs/libdrm-2.4.24[video_cards_nouveau?,video_cards_vmware?]
video_cards_nouveau? ( <x11-libs/libdrm-2.4.34 )
video_cards_intel? ( >=x11-libs/libdrm-2.4.24[video_cards_intel] )
video_cards_radeon? ( >=x11-libs/libdrm-2.4.24[video_cards_radeon] )

Could instead be written as:

>=x11-libs/libdrm-2.4.24[video_cards@nouveau,vmware?]
video_cards@nouveau,intel,radeon? ( 
  <x11-libs/libdrm-2.4.34[video_cards@intel,radeon?] )

Another example, just from randomly poking through the tree: 
app-admin/chef-server-api; I get the feeling this likely applies to 
most ruby pkgs.  Abbreviated rdeps are thus:

ruby_targets_ruby18? (
  ~app-admin/chef-10.12.0[ruby_targets_ruby18]
  >=dev-ruby/dep_selector-0.0.3[ruby_targets_ruby18]
  .. 12 more pkgs w/ similar use enforcement ..
)

ruby_targets_ruby19? (
  ~app-admin/chef-10.12.0[ruby_targets_ruby19]
  >=dev-ruby/dep_selector-0.0.3[ruby_targets_ruby19]
  .. 12 more pkgs w/ similar use enforcement ..
)

Instead, it could be written as thus:

ruby_targets@ruby18,ruby19? (
  ~app-admin/chef-10.12.0[ruby_targets@ruby18,ruby19?]]
  >=dev-ruby/dep_selector-0.0.3[ruby_targets@ruby18,ruby19?]
  .. 12 more pkgs w/ similar use enforcement ..
)

Upshot of that approach, it's effectively a single atom- meaning we 
don't have to worry about the scenario where (just hypothetically 
speaking) app-admin/chef was a slotted pkg; the current form they 
have in the tree, were it slotted, the resolver could pull in two 
there even if the pkg didn't want it to.

I'd be curious exactly what people think of that extension; 
technically, there is no reason it couldn't be used outside of just 
use_deps also.

Finally, keep in mind that the syntax for multiple flags there is 
intentionally a bit loose; that can be debated/bikeshedded to hell; 
the point however is that while we could try doing similar w/ old 
USE_EXPAND syntax, that's fairly ugly; the new '@' syntax makes this 
easier and opens up potentials.


-- ability to do testing of use groups (multiple flags) as a whole --

Continuing from the ruby example, we have a ruby use flag, then 
use_expanded ruby_targets_ruby${version}.  There's no reason the ruby 
use flag couldn't be killed off, and instead, allow 'ruby@? ( 
ruby-deps )' syntax- or something possibly more syntactically 
tasteful, 'ruby@*? ( ruby-deps )'.


-- Sub use groups --

There's no reason we couldn't do nesting of namespaces here; 
apache2_modules for example has the following optionals:

proxy - HTTP/1.1 proxy/gateway server
proxy_ajp - AJP support module for mod_proxy
proxy_balancer - mod_proxy extension for load balancing
proxy_connect - mod_proxy extension for CONNECT request handling
proxy_ftp - FTP support module for mod_proxy
proxy_http - HTTP support module for mod_proxy
proxy_scgi - SCGI gateway module for mod_proxy

If we wanted to, w/ the new syntax we could fairly easily nest that, 
such that it's apache2_modules@proxy@ajp, 
apache2_modules@proxy@balancer... you get the idea.  Note this isn't 
required- it just becomes sanely possible w/ the syntax.

-- REQUIRED_USE enhancement --

It's late, so I'm going light on the details for this; essentially, 
the ability to address a bunch of flags at once I'm strongly wager 
devs will find a use for.  My brains a bit fried, but if folks have an 
example in this case, please chime in.


Again, sorry for the length, but hopefully having read this far, 
it wasn't a waste of your time. ;)

If folks want to pick at specific sub-uses of the syntax, please feel 
free to change the subject for that feature and derive a thread from 
it (think git patchset uploads, and you'll grok the notion).

~harring