1 |
On Friday 12 December 2003 21:27, Jason Stubbs wrote: |
2 |
> Hello all, |
3 |
> |
4 |
> I've been thinking on the idea of USE flags and am wondering what the |
5 |
> developers' perspective is. They are defined in "Gentoo Guide to USE |
6 |
> flags" as "keywords that define options used on a system-wide basis |
7 |
> to configure applications during their respective compilation |
8 |
> procedures". Is there any other, more formal, definition? |
9 |
|
10 |
One thing that I think should be changed is the way that now they are |
11 |
USE flags ie binary valued variables. I would like to have these as |
12 |
multivalue variables, which then could be used in the following way. |
13 |
|
14 |
use.gui.gtk 10,qt 1,curses allways |
15 |
|
16 |
or using alternate more readable syntax |
17 |
|
18 |
use.gui.gtk 10 |
19 |
+use.gui.qt 1 |
20 |
+use.gui.curses allways |
21 |
|
22 |
So if I would have a packages that possibly has any of the three |
23 |
different possible gui's the above definition would compile the |
24 |
pacakges as follow. |
25 |
|
26 |
If the package has curses support the support is allways included. |
27 |
If it has qt and no gtk support then qt is used. |
28 |
If gtk is supported it will take place as the higer priority gui. |
29 |
|
30 |
If there is more than one allways qui's, but all of them are not |
31 |
supported at the same time so instead of allways we possibly could use |
32 |
to priority types look below. |
33 |
|
34 |
> My reason for asking is that my feel, from the way developers and |
35 |
> experience users talk about USE flags, that their usage has been |
36 |
> mostly restricted to options provided by configure scripts. This is |
37 |
> natural as (I assume) that's the way that USE flags evolved. However, |
38 |
> I think that the the purpose of USE flags needs to be rethought, when |
39 |
> implemented in portage-ng, to include how USE flags pertain to the |
40 |
> system as a whole. |
41 |
|
42 |
And here I give another possibility that could be used as a multi valued |
43 |
variable. |
44 |
|
45 |
use.X never |
46 |
|
47 |
This definition would simply block any tries to install something that |
48 |
would need an X-server to be runned. |
49 |
|
50 |
So we would need a definition for the ebuilds like the following. |
51 |
|
52 |
in xfree ebuild: |
53 |
|
54 |
never_use=use.X |
55 |
|
56 |
This would mark that this ebuild can't be installed when the useflag |
57 |
use.X is set to never. This same thing could be used to block say Gnome |
58 |
or KDE or ... |
59 |
|
60 |
|
61 |
Here are some things to thought for this kind of system. |
62 |
|
63 |
What kinds of values except priority we allow? |
64 |
should we have type defined the use 'flags'? |
65 |
This is quite hard, but it would be better if we could manage using |
66 |
only one type of variables even if the type would be quite complex. |
67 |
|
68 |
If yes what kind of different types we need? |
69 |
The earlier mentioned gui example could has two allways stated gui's, |
70 |
but if only one of them can be used then we would need two |
71 |
different numerical value types. As an example: |
72 |
use.gui.gtk allways 10 |
73 |
-use.gui.qt |
74 |
+use.gui.curses allways |
75 |
This would add gtk and curses allways, but if only one of them can be |
76 |
used then it is gtk. Qt support is disabled in this example. |
77 |
|
78 |
Do we need multiple numerical types, or can we use simply one numerical |
79 |
type and interpret it differently as needed. |
80 |
|
81 |
How to make this efficient? |
82 |
In my mind this need's a database, but in my mind all portage stuff |
83 |
should be in a database, but that's another story at the moment ( I'm |
84 |
thinking it constantly, and the idea is heading out, but I need to |
85 |
write it down first). |
86 |
|
87 |
|
88 |
|
89 |
|
90 |
I should state the difference of following two definitions to make sure |
91 |
everybody understands what the heck I'm talking about. :) |
92 |
|
93 |
-use.X |
94 |
use.X never |
95 |
|
96 |
The former is mild forbid. So if the support is not required to use the |
97 |
application, then the application can be used. It will be without the |
98 |
support for X though. The second definition simply says that if one |
99 |
ever tried to install package that would install X, then this package |
100 |
can't be installed. |
101 |
|
102 |
Applications that has optional support for X can be use though, because |
103 |
they can be compiled without X support. So in the first case X server |
104 |
itself can be installed excplicitly, but in the later it can't be |
105 |
installed at all. |
106 |
|
107 |
|
108 |
|
109 |
|
110 |
|
111 |
|
112 |
And here are the examples of my definitions as they would be in a config |
113 |
file (remember that I would put these in the DB). |
114 |
|
115 |
=use.gui.gtk prefer 10 # Any other gui variables, but gtk are forbiden |
116 |
+use.gui.gtk prefer 10 # Only affects the value of the gtk variable |
117 |
-use.gui.gtk # Only disables gtk support |
118 |
-use.gui.gtk prefer 10 # Same thing, because the value is ignored |
119 |
!use.gui.gtk # Forbids installation of gtk and gtk apps |
120 |
+use.gui.gtk never # Same thing |
121 |
-use.gui.gtk never # Not same thing the never is ignored |
122 |
|
123 |
So this has a grammar of something like this |
124 |
|
125 |
definition = <operation><variable> |
126 |
|
127 |
|
128 |
|
129 |
And some dangerous examples to show that the powerfull absolute denial |
130 |
definitions should be thought well before using. |
131 |
|
132 |
!use.gui # Forbids all packages that use any GUI variables |
133 |
!use # Forbids all packages that use any USE variables |
134 |
|
135 |
|
136 |
So now comments are welcome. :) |
137 |
|
138 |
|
139 |
-- |
140 |
gentoo-portage-dev@g.o mailing list |