1 |
On Thu, 2 Feb 2017 18:01:54 -0600 |
2 |
Gordon Pettey <petteyg359@×××××.com> wrote: |
3 |
|
4 |
> If you want to keep this kind of thing in the ebuilds, IUSE="+blah" doesn't |
5 |
> allow any granularity. Another variable USE_PROFILE should be added |
6 |
> analogue to DEPENDS: |
7 |
> IUSE="gnome-keyring gtk-theme kwallet pulseuadio qt-theme |
8 |
> annoyingUpstreamDefault" |
9 |
> USE_PROFILE=" |
10 |
> desktop? ( pulseaudio ) |
11 |
> gtk? ( gtk-theme ) |
12 |
> gnome? ( @gtk gnome-keyring) |
13 |
> kde? ( @qt kwallet ) |
14 |
> qt? ( qt-theme ) |
15 |
> upstream? ( annoyingUpstreamDefault ) |
16 |
> " |
17 |
|
18 |
This is the way I'd suggest going as well. Mostly, because needless double-accounting |
19 |
by communicating this same information to a global profile seems like creating |
20 |
work without benefit. |
21 |
|
22 |
I'd probably suggest something like this, but with a restriction that every |
23 |
"foo?" on the left hand side being a defined global term. |
24 |
|
25 |
Especially considering that USE="-*" doesn't necessarily give you "less dependencies", |
26 |
in the case of dev-util/pkgconfig, USE="-*" aligns with the existing (default) mechanic |
27 |
of USE="-internal-glib", and so a "minimal system" would either |
28 |
|
29 |
a. Prefer dev-util/pkgconf which doesn't require glib at all ( bug #606260 [1] ) |
30 |
|
31 |
b. Prefer USE="internal-glib" |
32 |
|
33 |
Clearly given bug #606260, our current mechanism of following upstream defaults |
34 |
is not ideal for minimal systems, even though its fine for 99.99% of users. |
35 |
|
36 |
Hence, I'd prefer something akin to: |
37 |
|
38 |
virtual/pkgconfig: |
39 |
|
40 |
RDEPEND=" |
41 |
profile:minimal? ( |
42 |
|| ( dev-util/pkgconf dev-util/pkgconfig[internal-glib] dev-util/pkgconfig ) |
43 |
) |
44 |
+profile:upstream? ( |
45 |
|| ( dev-util/pkgconfig dev-util/pkgconf ) |
46 |
) |
47 |
" |
48 |
|
49 |
Granted here I'm stepping slightly outside the conversation of USE defaults, because |
50 |
this is a related system where the concepts of defaults are present, but are instead |
51 |
regulated by implicit controls based on what the user has already decided to install. |
52 |
|
53 |
And this example suggested usage is a bit dodgy because it could be abused by people |
54 |
using profiles instead of useflags to control behaviour. |
55 |
|
56 |
However: |
57 |
|
58 |
IUSE="minimal" |
59 |
IUSE_PROFILES=" |
60 |
minimal? ( minimal ) |
61 |
" |
62 |
RDEPEND=" |
63 |
minimal? ( |
64 |
|| ( dev-util/pkgconf dev-util/pkgconfig[internal-glib] dev-util/pkgconfig ) |
65 |
) |
66 |
!minimal? ( |
67 |
|| ( dev-util/pkgconfig dev-util/pkgconf ) |
68 |
) |
69 |
" |
70 |
|
71 |
Would be less abusey. |
72 |
|
73 |
Also, this approach in general means instead of needing repoman to compute the interaction |
74 |
of <Profile X> x <Profile Y> for all(@profiles), it only needs to compute the interactions |
75 |
for Profile X x Profile Y for union(x.profiles y.profiles) |
76 |
|
77 |
( Though personally I don't think repoman needs to compute anything for defaults, |
78 |
I just saw somebody else mention this in a different part of this thread and it confused |
79 |
me. However, it *could* be useful to be able to ensure cohesion within a single chosen |
80 |
profile name, being able to state "If you set your profile to X and don't change anything |
81 |
in package.use, everything that has profile X will be installable as-is" ) |
82 |
|
83 |
And this of course brings into observation my favourite negative-useflag, |
84 |
for which USE="-*" will have the opposite effect to that you intend. |
85 |
|
86 |
__ SIMPLIFIED __ |
87 |
|
88 |
# May contain only the possible useflags, not setting defaults |
89 |
IUSE="" |
90 |
|
91 |
# A list of "profilename ? ( assumed defaulted on flags )" |
92 |
# where "profilename" must be a defined profile ID |
93 |
# "profilename" can have a "+" to indicate it is the default profile |
94 |
# if none of the others listed in IUSE_PROFILES matches a user description |
95 |
|
96 |
IUSE_PROFILES="" |
97 |
|
98 |
|
99 |
> @ is already used for sets, so "some other use_profile's set of defined |
100 |
> flags" seems reasonable. It should be additive only, so no +- prefixes |
101 |
> needed (or allowed). If a package is emerged without any USE_PROFILE set, |
102 |
> you might einfo "This package supports was emerged with no use profile. It |
103 |
> supports blah1, blah2, and blah3. Upstream recommends blah2." USE_PROFILE |
104 |
> should never have any default selected by an ebuild; if a flag is required |
105 |
> to build, is shouldn't be a flag. You get independent behavior per package |
106 |
> rather than listing every single package that ever existed in |
107 |
> profile/package.use, package behavior actually being with the package |
108 |
> instead of global profiles, and you get rid of the mess of uncustomizable |
109 |
> IUSE="+something" everywhere that makes people like me tend to start off |
110 |
> every new Gentoo install with echo "USE=\"-*\"" >> /etc/portage/make.conf. |
111 |
> Just need to come up with sane naming convention for common possibilities |
112 |
> like kde, gnome, and generic desktop. |
113 |
|
114 |
Personally, I think encouraging people to set profiles on a per-package level |
115 |
fights the cause of this feature in ways that should be governed by USE flags. |
116 |
|
117 |
The real utility of profile-governed defaults is that you should select a given |
118 |
profile, and *everything* should work out of the box *without* needing to change |
119 |
use flags, and repoman should compute how "my profiles defaults expanded into dependencies" |
120 |
would introduce a need to change USE flags on dependencies, and should raise |
121 |
warnings when this happens. |
122 |
|
123 |
If A and B both have 2 profiles each, and depend on a third package C, |
124 |
which has only 0 or 1 profiles (ie: "the only profile is a default profile"), |
125 |
then as long as both A and B's profiles don't require changes in C, this should |
126 |
be "legal" |
127 |
|
128 |
C could enhance things later by adding an additional profile more in line with |
129 |
A and B, changing the defaults to get closer to the ideals that profile defines. |
130 |
|
131 |
And if A and B have profiles that necessitate C changing use flags, that should |
132 |
cause repoman to error until a suitable profile is added to C that matches |
133 |
A and B. |
134 |
|
135 |
|
136 |
Though yes, I understand I'm kinda thinking of a different way to implement |
137 |
mixin profiles without necessitating a lot of global state to regulate it, so |
138 |
mgorny probably hates me. |
139 |
|
140 |
> |
141 |
> If you want upstream, USE_PROFILE="upstream". If Gentoo as an organization |
142 |
> wants that to be the "friendly to new user" standard, put |
143 |
> USE_PROFILE="upstream" in the stage3 make.conf, where those of us who want |
144 |
> to can simply remove or change it instead of having to nuke everything with |
145 |
> USE="-*". You can still use e.g. RUBY_TARGETS="+ruby21" in an ebuild if you |
146 |
> want a default for things that really require an at-least-one-of choice. |
147 |
> |
148 |
> Then instead of default/linux/amd64/13.0/desktop/kde listing any USE flags |
149 |
> itself, it just sets required USE_PROFILE and lets the packages do their |
150 |
> thing. |
151 |
|
152 |
The only thing left that leaves me in a state of "ugh, this could be ugly" |
153 |
is how application of multiple profile-use should be handled, if we go that way. |
154 |
|
155 |
Naturally some packages A and B will have different profiles, and so you'll |
156 |
want to pick 2 ... |
157 |
|
158 |
I guess this is where 'additive only' is helpful to an extent, but this |
159 |
opens complexity city where additive unioning of multiple profiles |
160 |
in a single package end up introducing a REQUIRED_USE mutual-exclusion, |
161 |
thwarting the incentive for profiles entirely. |
162 |
|
163 |
Unless ... |
164 |
|
165 |
|
166 |
IUSE_PROFILES=" |
167 |
desktop & upstream & !gtk & !gnome -> ( qt ) |
168 |
desktop & upstream & ( gtk | gnome ) -> ( gtk qt ) |
169 |
desktop & !upstream & ( gtk | gnome ) -> ( gtk ) |
170 |
" |
171 |
|
172 |
Ugh. No. This is all horrible. My head hurts just thinking about it. |
173 |
|
174 |
Freedom of Choice is freedom to suffer in new and innovative ways. |
175 |
|
176 |
1: https://bugs.gentoo.org/606260 |