1 |
Hello all, |
2 |
|
3 |
At the risk of sounding precocious, I think I'm going to open another can of |
4 |
worms. ;-) |
5 |
|
6 |
I've been thinking on the idea of USE flags and am wondering what the |
7 |
developers' perspective is. They are defined in "Gentoo Guide to USE flags" |
8 |
as "keywords that define options used on a system-wide basis to configure |
9 |
applications during their respective compilation procedures". Is there any |
10 |
other, more formal, definition? |
11 |
|
12 |
My reason for asking is that my feel, from the way developers and experience |
13 |
users talk about USE flags, that their usage has been mostly restricted to |
14 |
options provided by configure scripts. This is natural as (I assume) that's |
15 |
the way that USE flags evolved. However, I think that the the purpose of USE |
16 |
flags needs to be rethought, when implemented in portage-ng, to include how |
17 |
USE flags pertain to the system as a whole. |
18 |
|
19 |
I was half thinking about it when I wrote the following except from my last |
20 |
mail: |
21 |
|
22 |
On Tuesday 09 December 2003 07:06, Jason Stubbs wrote: |
23 |
> USE flags need to be able to be grouped into 'super-USE' flags. For example: |
24 |
> "multimedia", "workstation", "server", etc. |
25 |
> where "multimedia" = "video-codecs", "audio-codecs", "media-recording", etc. |
26 |
> where "video-codecs" = "avi", "divx", "dvd", etc. |
27 |
|
28 |
I'm going to expand on this idea a little, although I think it might not be |
29 |
well received due to the unexplained fear of USE flag explosion. My idea is |
30 |
that USE flags should be somewhat the equivalent of Microsoft Windows |
31 |
Installer's Product Feature selection tree, the main difference being that it |
32 |
applies to the whole operating system. |
33 |
|
34 |
To explain further, I will again use an example possibility: |
35 |
Multimedia |
36 |
+ Recording |
37 |
- Playback |
38 |
+ Video |
39 |
- Audio |
40 |
+ Audio Codecs |
41 |
- Audio Providers |
42 |
- OSS |
43 |
- ALSA |
44 |
- ARTS |
45 |
- ESD |
46 |
- <default> |
47 |
|
48 |
From this small excerpt of a possible tree, you can image how big a full tree |
49 |
would be. The benefits of this style of tree are manyfold, but I'll just go |
50 |
over a few of the obvious (to me): |
51 |
|
52 |
* Finer grain of control |
53 |
|
54 |
Depending on what is actually implement of course, this model can offer much |
55 |
more control. If the above example is extended to include ALSA drivers, the |
56 |
model is shown to become a unified way to model all option behaviour of |
57 |
packages. Mozilla, for example, could be done in exactly the same way. |
58 |
|
59 |
* Better categorization |
60 |
|
61 |
With this USE flag model, if an ebuild-ng specifies what functionality it |
62 |
provides, both intrisically and optionally, packages become very easy to find |
63 |
for the end-user. It will also be easy to find other packages that do same |
64 |
things as a package that the user is familiar with. |
65 |
|
66 |
That's all that I can think of at the moment. The only negative thing I can |
67 |
see is the explosion of USE flags. However, this is only a bad thing if they |
68 |
are uncategoriezed. Proper categorization should actually make them easier to |
69 |
understand and easier to maintain. |
70 |
|
71 |
Well, that's enough said for now. All constructive criticism and any additions |
72 |
welcome. |
73 |
|
74 |
-- |
75 |
Regards, |
76 |
Jason Stubbs |
77 |
|
78 |
-- |
79 |
gentoo-portage-dev@g.o mailing list |