1 |
On Tue, 7 Jun 2016 14:29:58 -0400 |
2 |
Michael Orlitzky <mjo@g.o> wrote: |
3 |
|
4 |
> On 06/07/2016 12:20 PM, Michał Górny wrote: |
5 |
> > |
6 |
> > So many weird ideas... while the simplest one is a proper |
7 |
> > REQUIRED_USE with gui being the control flag, and IUSE defaults to |
8 |
> > select the preferred toolkit. |
9 |
> > |
10 |
> |
11 |
> This is what came to my mind. |
12 |
> |
13 |
> The underlying problem that we are hitting (a la Patrick) is that USE |
14 |
> flags are supposed to be a user-interface for building software from |
15 |
> source, but implementation details are an important part of |
16 |
> configuring the software to be built. |
17 |
> |
18 |
> It would be nice if USE=gui meant "build a GUI" and that was all the |
19 |
> input that we needed from the user. But if the upstream package |
20 |
> supports both QT and GTK and we need to pass either --with-qt or |
21 |
> --with-gtk to the build system, then there is an unavoidable choice |
22 |
> to be made. We can prefer one, but both options need to be available. |
23 |
> |
24 |
> If we want the best of both worlds -- a nice user-interface and full |
25 |
> configurability -- then we can use "the user wants a GUI" as a trigger |
26 |
> for the implementation choice. If there's a default implementation and |
27 |
> the user doesn't care, no further interference should be necessary. |
28 |
> Otherwise the presence of the generic USE=gui will let us know, so we |
29 |
> can let the user know, that he needs to pick one. |
30 |
> |
31 |
> |
32 |
|
33 |
This is where my thought from a few days ago kicks in... |
34 |
I had started to discuss it with Kristian. |
35 |
|
36 |
|
37 |
I propose to help alleviate the __MESS__ from all this force-foo and |
38 |
other complicated USE flag REQUIRED_USE madness... |
39 |
|
40 |
We instead implement something along the lines of: |
41 |
|
42 |
an ordered list of the gui toolkits in their preferred order of |
43 |
desirability. This should be an all inclusive list. Note: these are |
44 |
subject to package.use setting overrides. |
45 |
|
46 |
PREFERRED_GUIS="gtk2 qt4 qt5 x wxwidgets X ... ncurses tty -gkt3" |
47 |
|
48 |
In the above it means that if gtk2 is an option, then choose it, mask |
49 |
(de-select) the others. |
50 |
In there it also means DO NOT SELECT gtk3!!!! So if you want a pkg and |
51 |
it NEEDS gtk3, then the PM will puke it back at you saying you can't |
52 |
have one without the other... |
53 |
So, then you have to fix it manually via package.use settings. Accept |
54 |
gtk3 for this pkg only (not that it doesn't likely have other gtk3 |
55 |
deps that will also need this...) |
56 |
|
57 |
In the general case it will pick the first toolkit in order of |
58 |
preference (left to right) and only that toolkit that the pkg is capable |
59 |
of using. |
60 |
|
61 |
For pkgs capable of multiple simultaneous toolkits installed, then |
62 |
again, manual intervention would be needed to set package.use. |
63 |
|
64 |
This would also have to be a package manager feature and run similar to |
65 |
the auto-unmask feature. |
66 |
|
67 |
FEATURES="preferred-guis" |
68 |
|
69 |
Let's try and keep things as simple as possible. |
70 |
From what I've gleaned form the emails I have read, is that what the |
71 |
general user wants to happen, select the toolkit in the order of their |
72 |
preference. |
73 |
-- |
74 |
Brian Dolbec <dolsen> |