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