Re: [gentoo-dev] Re: unifying use.mask/package.use.mask, use.force, package.use.force, etc

[Brian Harring]

On Mon, Sep 10, 2012 at 01:28:23AM +0000, Duncan wrote:
> Brian Harring posted on Sun, 09 Sep 2012 15:10:27 -0700 as excerpted:
>
> > [Current profile config to to mask the USE=introspection
> > globally, but unmask it for app-crypt/gcr]:
> >
> > use.mask:
> > introspection
> >
> > package.use.mask:
> > app-crypt/gcr -introspection
>
> > [Suggest killing package.* content, folding it into use.*]
>
> > use.mask:
> > * introspection
> > app-cryt/gcr -introspection
>
> > Specifically, collapsing:
> > package.use.mask, use.mask -> use.mask
> > package.use.force, use.force -> use.force
> > package.use.stable.mask, use.stable.mask -> use.stable.mask
> > package.use.stable.force, use.stable.force -> use.stable.force
>
> You mention doing this for the profile.

Not 'mention' the proposal *is a profiles modification* in entirety, 
nothing else.

Reorganizing the questions into user configuration (aka, the PM 
authors choice of what they want to do in /etc/portage/profiles), and 
PMS profiles (aka, what can be done in gentoo-x86).

user config first:

> ??  Would user's package.* and general make.conf settings remain the same?

That's the PM's decision.  Knowing portage source, I'd expect it'll 
wind up enabling that in parallel to the existing for it's user 
configuration.


> ??  What about user's existing /etc/portage/profile overrides, if any?

Same response; that's the PMs decision.  What Zac does, is what Zac 
does.

> ??  And if they change, are you proposing a script that a user can run to
> automate the process, or simply a news item pointing to the appropriate
> gentoo profile upgrade documentation page, or ??

{ cat use.mask | sed -e 's:^:* :'; cat package.use.mask; } > t \
  && mv t use.mask && rm package.use.mask


Actual PMS profiles question:

> ??  Are you proposing the change be only for new profiles, eventually
> deprecating the old ones, thus having the PMs (and devs maintaining
> profiles) support both methods for awhile much as the cascading profiles
> migration was handled?

Profile nodes are EAPI versioned; what I want, is effectively >=EAPI-5 
(or 6 if people get cranky about minor mods), is this to be the 
default in new EAPI profile nodes.

Meaning if someone uses a EAPI5 profile node in gentoo-x86, they don't 
use package.use.mask, they use the syntax I mentioned, and do it 
within use.mask.

There will not be maintaining in parallel; there isn't a point.


Basically, this is a ~70 file reduction of profiles; 253 -> 184 
roughly.  Aside from less general IO (not much, but some), it also 
kills of the question for devs as to which comes first; use.mask or 
package.use.mask.  Ordering of the file would rule in the new scheme.

Frankly if we wanted to, we could push this further; use.force and 
use.mask basically operate in a ternary space: -1, 0, +1; meaning 
"Forced off", "configurable", and "enforced on"; respecitively such a 
syntax would be -use, use, +use.

Thus the following:
use.mask:
blah
-monkeys # Note this is a negation of the parents masking of 'monkeys'
-foon # Negation of the parents masking

package.use.mask:
dev-util/bsdiff foon

use.force:
x
-y # negation of the parents forcing
monkeys  # Note we're explicitly forcing monkeys on after reversing 
# masking

package.use.force
dev-util/diffball strip

that translates out to basically thus:

use.enforced:
# This globally disables 'blah', globally forces 'monkeys',
# and resets 'foon' back to user controllable.
* -blah +monkeys foon
# Disable blah for dev-util/bsdiff.
dev-util/bsdiff -foon
# Force strip for dev-util/diffball.
dev-util/diffball +strip


The benefit of such an aproach is that
1) I'd argue it's easier on the dev for processing it- just proceed 
top down, for the pkg in question considering if each leading 
restriction (* or the atom) matches, then applying the resultant 
settings.

2) This actually is basically what the PM does now, although it does 
so via grabbing the content from multiple files.


In terms of performance gain, couldn't say frankly; pkgcore already 
does a variant of this, re-rendering each cat/pkg restriction set so 
as to avoid having to do the resolution multiple times (this helps 
repoman/pcheck speed for example).

That said I'm not sure if folks would go for the ternary usage there.  
Where that scheme to be applied to our profiles, it'd knock the inode 
count for these files down to 127.  Not the driving reason for it, but 
a nice benefit.
~harring