Gentoo Archives: gentoo-dev

From: Dennis Schridde <devurandom@×××.net>
To: gentoo-dev@l.g.o
Cc: Zac Medico <zmedico@g.o>, Michael Orlitzky <mjo@g.o>
Subject: Re: [gentoo-dev] Adding USE=udev to linux profiles
Date: Sat, 21 Jul 2018 14:45:39
Message-Id: 2326315.fczUOiFlLO@monk
In Reply to: Re: [gentoo-dev] Adding USE=udev to linux profiles by Zac Medico
1 On Saturday, 21 July 2018 11:33:23 CEST Zac Medico wrote:
2 > On 07/21/2018 12:01 AM, Dennis Schridde wrote:
3 > > On Friday, 20 July 2018 08:25:05 CEST Michael Orlitzky wrote:
4 > >> Yes, when you set USE=foo in profile A and USE="-foo" in profile A/B,
5 > >> the end result is USE="foo -foo" which is the same thing as USE="-foo".
6 > >> The default portage USE_ORDER makes the profile flags more important
7 > >> than IUSE defaults, so the USE="-foo" from the profile clobbers any
8 > >> IUSE="+foo" defaults.
9 > >>
10 > >> If no default was set in profile A, then no override would be necessary
11 > >> in profile A/B, and the resulting USE="" would not override the IUSE
12 > >> default.
13 > >
14 > > It appears to me that the difficulty stems from use flags being tri-state
15 > > (enabled, disabled, unset), but us having only operators to enable (+) and
16 > > disable (-) them in make.conf and profiles.
17 > >
18 > > What about adding a third operator, e.g. `^`, that resets a use flag to
19 > > the
20 > > unset state?
21 >
22 > Sure, why not? So ^flag would mean that the flag state propagates from
23 > the settings in IUSE.
24
25 It's important to note that, since profiles are applied hierarchically, this
26 mechanism would support the following setup:
27
28 * profile 3 inherits from 2 inherits from 1
29 - i.e. 1 is applied before 2 is applied before 3
30 * profile 1 enables the flag with +use, overriding IUSE defaults
31 * profile 2 resets the flag with ^use, removing the override
32 * profile 3 disables the flag with -use, overriding IUSE defaults
33
34 1. After applying profile 1, the flag is globally enabled and overrides IUSE
35 defaults, but can be overridden on a per-package basis
36 2. After applying profile 2 on top of 1, the flag is unset and IUSE defaults
37 will be respected again, as well as per-package settings
38 3. After applying profile 3 on top of 2 and 3, the flag is globally disabled
39 and overrides IUSE defaults again, but per-package settings could still
40 override this
41
42 This still uses the exact same mechanisms and paths to apply profiles and use
43 flags, just adding another capability along that path. This would make
44 profiles more flexible, but not add too much cognitive complexity.
45
46 > It's also conceivable that we could add a way for
47 > profiles to modify the effective IUSE defaults, via new operators in
48 > package.use or by introducing a new file such as package.use.default.
49
50 Currently, for the calculation of the effective use flags of a package, use
51 flags are applied in the following order (I could not find this algorithm in
52 PMS, so this is from memory):
53 1. global use flags from profiles and /etc/portage
54 1. /etc/portage/make.profile/parent*/make.defaults
55 2. /etc/portage/make.profile/make.defaults
56 3. /etc/portage/make.conf
57 2. IUSE defaults from the package's ebuild
58 - applied only if use flag still unset
59 3. per-package overrides from profiles, /etc/portage/profile and /etc/portage
60 1. /etc/portage/make.profile/parent*/package.use
61 2. /etc/portage/make.profile/package.use
62 3. /etc/portage/profile/package.use
63 4. /etc/portage/package.use
64 4. globally forced or masked use flags from profiles and /etc/portage/profile
65 1. /etc/portage/make.profile/parent*/use.{,stable.}{force,mask}
66 2. /etc/portage/make.profile/use.{,stable.}{force,mask}
67 3. /etc/portage/profile/use.{,stable.}{force,mask}
68 5. per-package forced or masked use flags from profiles and /etc/portage/
69 profile
70 1. /etc/portage/make.profile/parent*/package.use.{,stable.}{force,mask}
71 2. /etc/portage/make.profile/package.use.{,stable.}{force,mask}
72 3. /etc/portage/profile/package.use.{,stable.}{force,mask}
73
74 I hope I did not forget anything.
75
76 Your suggestion is to add a step between 2 and 3, in order to allow a profile
77 to override a package's defaults, correct?
78
79 Since this scheme appears to be rather complex already, I wonder whether it
80 could be simplified using the additional operators you suggested. Currently
81 we have these:
82
83 In USE:
84 * `flag`: Unconditionally enable
85 * `-flag`: Unconditionally disable
86
87 In IUSE:
88 * `+flag`: Enable if unset
89 * `-flag`: Disable if unset
90
91 Maybe we could add the following operators to USE:
92 * `?+flag`: Enable if unset
93 * `?-flag`: Disable if unset
94
95 Sadly, we cannot use the exact same syntax in USE and IUSE, because the `-
96 flag` in USE already has a meaning. Hence we need the `?` variant. For
97 symmetry and to support intuition we could add a `+flag` syntax to USE.
98
99
100 Because the algorithm for applying use flags appears already very complex
101 currently, we could add the following operators to USE to generalise USE and
102 thus simplify the logic:
103 * `!+flag`: Enable unconditionally and lock
104 * `!-flag`: Disable unconditionally and lock
105
106 A "locked" use flag would mean that it cannot be further modified, unless also
107 using the lock operator. I.e. only `!+flag` or `!-flag` can change the value
108 of a flag that was already previously set using `!+flag` or `!-flag`.
109
110 With this syntax we could also merge the various use.{force,mask} into
111 make.defaults and package.use.{force,mask} into package.use (I found ...force
112 and ...mask to be rather confusing) and use the following simplified
113 calculation:
114 1. global use flags from profiles' and /etc/portage
115 1. /etc/portage/make.profile/parent*/make.defaults
116 2. /etc/portage/make.profile/make.defaults
117 3. /etc/portage/make.conf
118 - The previous ".stable" files could be replaced by USE_IF_STABLE variables
119 2. IUSE defaults from the package's ebuild
120 - applied only if use flag still unset
121 3. per-package overrides from profiles' and /etc/portage
122 1. /etc/portage/make.profile/parent*/package.use{,.stable}
123 2. /etc/portage/make.profile/package.use{,.stable}
124 3. /etc/portage/package.use{,.stable}
125 - Generally I would suggest to also merge /etc/portage/profile into /etc/
126 portage and deprecate the former -- I found figuring out what is allowed
127 where to be confusing, when I was new to Gentoo
128 - We could also extend the repository operator `::` with a stable `::=` and
129 an unstable `::~` variant in order to get rid of the ".stable" files

Attachments

File name MIME type
signature.asc application/pgp-signature