On Saturday, 21 July 2018 11:33:23 CEST Zac Medico wrote: > On 07/21/2018 12:01 AM, Dennis Schridde wrote: > > On Friday, 20 July 2018 08:25:05 CEST Michael Orlitzky wrote: > >> Yes, when you set USE=foo in profile A and USE="-foo" in profile A/B, > >> the end result is USE="foo -foo" which is the same thing as USE="-foo". > >> The default portage USE_ORDER makes the profile flags more important > >> than IUSE defaults, so the USE="-foo" from the profile clobbers any > >> IUSE="+foo" defaults. > >> > >> If no default was set in profile A, then no override would be necessary > >> in profile A/B, and the resulting USE="" would not override the IUSE > >> default. > > > > It appears to me that the difficulty stems from use flags being tri-state > > (enabled, disabled, unset), but us having only operators to enable (+) and > > disable (-) them in make.conf and profiles. > > > > What about adding a third operator, e.g. `^`, that resets a use flag to > > the > > unset state? > > Sure, why not? So ^flag would mean that the flag state propagates from > the settings in IUSE.
It's important to note that, since profiles are applied hierarchically, this
mechanism would support the following setup:
* profile 3 inherits from 2 inherits from 1
- i.e. 1 is applied before 2 is applied before 3
* profile 1 enables the flag with +use, overriding IUSE defaults
* profile 2 resets the flag with ^use, removing the override
* profile 3 disables the flag with -use, overriding IUSE defaults
1. After applying profile 1, the flag is globally enabled and overrides IUSE
defaults, but can be overridden on a per-package basis
2. After applying profile 2 on top of 1, the flag is unset and IUSE defaults
will be respected again, as well as per-package settings
3. After applying profile 3 on top of 2 and 3, the flag is globally disabled
and overrides IUSE defaults again, but per-package settings could still
override this
This still uses the exact same mechanisms and paths to apply profiles and use
flags, just adding another capability along that path. This would make
profiles more flexible, but not add too much cognitive complexity.
> It's also conceivable that we could add a way for
> profiles to modify the effective IUSE defaults, via new operators in
> package.use or by introducing a new file such as package.use.default.
Currently, for the calculation of the effective use flags of a package, use
flags are applied in the following order (I could not find this algorithm in
PMS, so this is from memory):
1. global use flags from profiles and /etc/portage
1. /etc/portage/make.profile/parent*/make.defaults
2. /etc/portage/make.profile/make.defaults
3. /etc/portage/make.conf
2. IUSE defaults from the package's ebuild
- applied only if use flag still unset
3. per-package overrides from profiles, /etc/portage/profile and /etc/portage
1. /etc/portage/make.profile/parent*/package.use
2. /etc/portage/make.profile/package.use
3. /etc/portage/profile/package.use
4. /etc/portage/package.use
4. globally forced or masked use flags from profiles and /etc/portage/profile
1. /etc/portage/make.profile/parent*/use.{,stable.}{force,mask}
2. /etc/portage/make.profile/use.{,stable.}{force,mask}
3. /etc/portage/profile/use.{,stable.}{force,mask}
5. per-package forced or masked use flags from profiles and /etc/portage/
profile
1. /etc/portage/make.profile/parent*/package.use.{,stable.}{force,mask}
2. /etc/portage/make.profile/package.use.{,stable.}{force,mask}
3. /etc/portage/profile/package.use.{,stable.}{force,mask}
I hope I did not forget anything.
Your suggestion is to add a step between 2 and 3, in order to allow a profile
to override a package's defaults, correct?
Since this scheme appears to be rather complex already, I wonder whether it
could be simplified using the additional operators you suggested. Currently
we have these:
In USE:
* `flag`: Unconditionally enable
* `-flag`: Unconditionally disable
In IUSE:
* `+flag`: Enable if unset
* `-flag`: Disable if unset
Maybe we could add the following operators to USE:
* `?+flag`: Enable if unset
* `?-flag`: Disable if unset
Sadly, we cannot use the exact same syntax in USE and IUSE, because the `-
flag` in USE already has a meaning. Hence we need the `?` variant. For
symmetry and to support intuition we could add a `+flag` syntax to USE.
Because the algorithm for applying use flags appears already very complex
currently, we could add the following operators to USE to generalise USE and
thus simplify the logic:
* `!+flag`: Enable unconditionally and lock
* `!-flag`: Disable unconditionally and lock
A "locked" use flag would mean that it cannot be further modified, unless also
using the lock operator. I.e. only `!+flag` or `!-flag` can change the value
of a flag that was already previously set using `!+flag` or `!-flag`.
With this syntax we could also merge the various use.{force,mask} into
make.defaults and package.use.{force,mask} into package.use (I found ...force
and ...mask to be rather confusing) and use the following simplified
calculation:
1. global use flags from profiles' and /etc/portage
1. /etc/portage/make.profile/parent*/make.defaults
2. /etc/portage/make.profile/make.defaults
3. /etc/portage/make.conf
- The previous ".stable" files could be replaced by USE_IF_STABLE variables
2. IUSE defaults from the package's ebuild
- applied only if use flag still unset
3. per-package overrides from profiles' and /etc/portage
1. /etc/portage/make.profile/parent*/package.use{,.stable}
2. /etc/portage/make.profile/package.use{,.stable}
3. /etc/portage/package.use{,.stable}
- Generally I would suggest to also merge /etc/portage/profile into /etc/
portage and deprecate the former -- I found figuring out what is allowed
where to be confusing, when I was new to Gentoo
- We could also extend the repository operator `::` with a stable `::=` and
an unstable `::~` variant in order to get rid of the ".stable" files
signature.asc
Description: This is a digitally signed message part.
