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

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

[Brian Harring]

Hola folks.

Currently, our if you needed to mask the use flag introspection 
globally, but allow it to be used for say app-crypt/gcr, the profile 
configuration would be the following:

use.mask:
introspection

package.use.mask:
app-crypt/gcr -introspection

Frankly, this is a bit of a pain in the ass- it creates a shiteton of 
intermediate files, and it requires the dev to recall "use.mask before 
package.use.mask" among other things.

I'd suggest instead just killing off the package.* content, and 
folding them into use.*; the proceeding content would thus be:

use.mask:
* introspection
app-cryt/gcr -introspection

Mind you, this isn't a new notion; actually pretty damn old 
(been in user configuration in one form or another for a long 
time).  For whatever reason, it's yet to be proposed/pushed for in 
PMS, thus bringing it up now.

Any major complaints?  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

~harring

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

[Duncan]

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.

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

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

??  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?  By definition, at least user's current /etc/
portage/profile/ settings are in the current format, so if you continue 
to support that, you'll in effect continue to support the old profile 
format, and (from the PM viewpoint) migration might as well be via new 
profiles and current profile deprecation, but that will force profile 
maintainers to maintain both for whatever period.

??  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 ??


In general, the idea seems like an eventual efficiency gain and I'm not 
opposed, but I do wonder if the gain is actually going to be worth it in 
practice, given the above.  Still, I'm not opposed, but I tend to be 
rather more leading edge and less opposed to change than most users in 
any case, and I'd guess a significant number of both users and devs that 
will be trying to support them (and both sets of profiles if the profile 
deprecation and upgrade migration method is chosen), will have rather 
stronger ideas about the practical cost/benefit ratio of such a change.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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