1 |
> I drafted that mentioned USE_EXPAND idea as a means to get some |
2 |
> 'design from the scratch' discussion going and flesh out this way of |
3 |
> potentially doing it (such a USE_EXPAND was idly mentioned at start |
4 |
> by |
5 |
> others as something that was deemed too crazy, but I didn't find any |
6 |
> references). It is currently still as a draft over at |
7 |
> http://piratepad.net/iwvgjB1P5d |
8 |
|
9 |
For the javascript restricted and for purposes of in-line quoted |
10 |
replies, here's the current state of my braindump there copied to e- |
11 |
mail here: |
12 |
|
13 |
|
14 |
The following draft concerns only applications. |
15 |
Libraries should continue using qt4 and qt5 USE flags when they are |
16 |
about libraries (linking against qt4 or qt5), where it's mostly a |
17 |
matter of USE depends by consumer apps or higher level libraries, not |
18 |
user choice for applications. |
19 |
For gtk case, we would use IUSE="gtk2" and IUSE="gtk3" in this case, |
20 |
but ideally they would be in separate slots or packages. In gtk case, |
21 |
this is for things like avahi, gtk-vnc, caribou, libcanberra - things |
22 |
that provide a library or module that links against given gtk SLOT or |
23 |
implements a gtk module for that SLOT with the given IUSE. |
24 |
The remainder concerns only applications, as we don't like to use the |
25 |
same flag name for different concepts (library support vs application |
26 |
toolkit version choice), and USE="gtk" might be something we could |
27 |
perhaps get rid of, in favor of moving gtk2 libraries to IUSE="gtk2" |
28 |
and application choice to IUSE="gui" or the proposed GUI USE_EXPAND. |
29 |
|
30 |
|
31 |
|
32 |
use.desc: |
33 |
|
34 |
gui - Enable an optional GUI |
35 |
|
36 |
use.desc/gui.desc: |
37 |
|
38 |
athena - Choose the MIT Athena widget set |
39 |
gtk - Build a <pkg>x11-libs/gtk+</pkg> based GUI |
40 |
motif - Build a <x11-libs/motif> toolkit based GUI |
41 |
sdl - ... |
42 |
qt4 - Build a Qt4 toolkit based GUI |
43 |
qt5 - Build a Qt5 toolkit based GUI |
44 |
wxwidgets - Build a wxWidgets based GUI |
45 |
Xaw3d - Build a 3d athena widget set based GUI |
46 |
|
47 |
|
48 |
Many of current IUSE=gtk should move to IUSE=gui when it's about |
49 |
application GUIs. |
50 |
Some of IUSE=gtk will move to version specific IUSE=gtk2 and IUSE=gtk3 |
51 |
when it's about libraries. |
52 |
Not sure if anything will remain then. If it does, we'll need to think |
53 |
about it then, or figure it out of the masses of IUSE=gtk users |
54 |
beforehand. |
55 |
An old mapping was partially conducted a while ago on https://docs.goog |
56 |
le.com/spreadsheets/d/19sJuupspkY65FrU6b4U7gEWKiOgFGQwyXYdPCAvPqBo/edit |
57 |
#gid=0 |
58 |
|
59 |
In no circumstance is a REQUIRED_USE or an equivalent pkg_pretend |
60 |
limitation allowed when dealing with gui USE_EXPAND. |
61 |
|
62 |
- A package has optional support for a GUI, written in any GUI toolkit |
63 |
(but only one) |
64 |
-- IUSE="gui" and depend and build against the toolkit it uses. No |
65 |
toolkit specific USE_EXPAND should exist, as there's nothing to choose. |
66 |
Example: wicd. USE="gui" shall build the gtk based GUI |
67 |
|
68 |
- A package has optional support for a GUI, and that GUI can be chosen |
69 |
to be either gtk, qt4 or qt5 based, but only one of them |
70 |
-- IUSE="gui gui_gtk gui_qt4 gui_qt5". If user has USE="gui" disabled |
71 |
for the package, don't build any GUI. If it's enabled, have a |
72 |
maintainer chosen preferred order of toolkit to use, then choose |
73 |
whichever highest priority toolkit flag is enabled by user. If no |
74 |
supported toolkit flag is chosen, choose the highest priority one. |
75 |
Example: ??? |
76 |
|
77 |
- A package has a required GUI, but the GUI can be chosen to be either |
78 |
gtk, qt4 or qt5 based, but only one of them |
79 |
-- Same as previous, but no IUSE="gui" as a GUI is not optional |
80 |
Example: ??? |
81 |
|
82 |
- A package has optional GUI frontends in a way that multiple can be |
83 |
built and shipped at once. |
84 |
-- IUSE="gui" to have any GUI at all, if user hasn't it set, gui_* |
85 |
values do not matter - no GUI will be built at all. If user has |
86 |
USE="gui" set, all of the user enabled gui_* frontends will be built. |
87 |
If user has no gui_* enabled at all that this package implements, but |
88 |
USE="gui" is set, then a maintainer chosen first choice GUI is built. |
89 |
Example: transmission with IUSE="gui gui_gtk gui_qt" |
90 |
|
91 |
- Same case as previous, but some toolkits are exclusive, e.g one can |
92 |
build both a gtk frontend and a qt frontend, but not both qt4 and qt5 |
93 |
frontend. |
94 |
-- Same USE="gui" behaviour. If multiple exclusive flags are set, they |
95 |
have an independent priority order, similar to when only one can be |
96 |
built. So with GUI="gtk qt4 qt5", a gtk and a qt5 frontend would be |
97 |
built when both qt4 and qt5 can't be. To choose qt4 frontend, qt5 has |
98 |
to be disabled by user for this package. |
99 |
|
100 |
- Same as prior 2 cases but a GUI is not optional (e.g lack of frontend |
101 |
doesn't make sense) |
102 |
-- Same, but no IUSE="gui" |
103 |
|
104 |
|
105 |
|
106 |
Suggestions for users approach of the GUI="" setting in make.conf: |
107 |
|
108 |
* If you don't care which toolkit is used, but rather would have the |
109 |
preferred one chosen for you, don't set it at all, but keep it empty. |
110 |
Do set USE="gui" if you want a GUI for where it's optional. |
111 |
* If you strongly prefer a given toolkit or toolkits, set that/those in |
112 |
GUI="..."; it will be then chosen whenever possible (if multiple, a |
113 |
maintainer decided preference will be chosen, if only one toolkit |
114 |
frontend is available; otherwise all of them will be built). If the |
115 |
program doesn't support building against that toolkit, a different |
116 |
choice will automatically be made for you. If you want to tweak that |
117 |
choice (e.g it pulls in a toolkit you want to avoid completely), tweak |
118 |
the flags in package.use |
119 |
|
120 |
Raised concerns: |
121 |
|
122 |
* With gui as the USE_EXPAND, a GUI variable from make.conf will |
123 |
apparently be exported to all ebuild environments, even if not used, |
124 |
which might mean something for the build environment of the given |
125 |
package. |
126 |
* The dependency conditionals can get very messy with the priority list |
127 |
of toolkits |
128 |
|
129 |
Possible future improvement ideas: |
130 |
|
131 |
* Make USE_EXPAND able to declare a priority list at ebuild level with |
132 |
some syntax, so that it would express it once, and then unset the GUI |
133 |
choices that won't be used due to exclusivety for DEPEND parsing, to |
134 |
make this clearer. Then this priority can be expressed to the user |
135 |
somehow by PM. |
136 |
* Record the filtered choices made in VDB (or similar for other PMs), |
137 |
so the package manager would know which toolkit was actually chosen. |
138 |
* Allow giving a priority for users as well, e.g GUI="1|gtk 2|qt4 |
139 |
2|qt5" or some different syntax, which would then influence that |
140 |
priority when possible (in this case prioritize gtk over others, and |
141 |
qt4/qt5 have equal priority over that - as they are equal, the ebuild |
142 |
priority between them counts instead). |
143 |
|
144 |
This might then morph it into something other than USE_EXPAND in |
145 |
terminology, but till then, USE_EXPAND allows us to group the choices |
146 |
into one logical block. |