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
