FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-09-2012, 10:10 PM
Brian Harring
 
Default unifying use.mask/package.use.mask, use.force, package.use.force, etc

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
 
Old 09-10-2012, 01:28 AM
Duncan
 
Default unifying use.mask/package.use.mask, use.force, package.use.force, etc

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
 
Old 09-10-2012, 03:23 AM
Brian Harring
 
Default unifying use.mask/package.use.mask, use.force, package.use.force, etc

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
 

Thread Tools




All times are GMT. The time now is 09:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org