1 |
Hello, |
2 |
|
3 |
I've did a quick statistic of how often USE_EXPAND flags are used. |
4 |
In order to obtain the results, I have put all known USE_EXPANDs into |
5 |
${flags[@]} and then did: |
6 |
|
7 |
for a in "${flags[@]}"; do |
8 |
echo -n "$a: " |
9 |
grep -l IUSE=.*${a}_ */* | xargs qatom | cut -d' ' -f1-2 | sort -u |
10 |
| wc -l done | tee /tmp/use-expand.txt |
11 |
|
12 |
The result was a table of USE_EXPAND flags with counts of how many |
13 |
*different* packages declare them in IUSE. |
14 |
|
15 |
The results are: |
16 |
|
17 |
package count | n flags |
18 |
---------------+--------- |
19 |
0 | 3 |
20 |
1 | 24 |
21 |
2 | 4 |
22 |
3-8 | 3 |
23 |
>10 | 11 |
24 |
|
25 |
As you can see, we have *a lot* of USE_EXPAND variables which are only |
26 |
used by a *single* package. This feels a lot like people are overusing |
27 |
USE_EXPANDs in place of local USE flags, just to have them prefixed. |
28 |
And if you take a look at the detailed list (attached for |
29 |
completeness), you can see that they really do. |
30 |
|
31 |
And if anyone wondered why it's wrong -- it's wrong because it's much |
32 |
like declaring global USE flags for a very specific features which are |
33 |
not only specific to a single package, but are even defined in a way |
34 |
that they will *never* be suitable to anything else. |
35 |
|
36 |
Although most of the cases need to be handled separately |
37 |
and specifically to a particular flag, a common mistake is to introduce |
38 |
USE_EXPAND every time plugins or modules are involved. |
39 |
|
40 |
People, plugins are *not* special. There are regular features, just |
41 |
packaged in a bit different way. |
42 |
|
43 |
Let's take an example of a mail client. We have two mail clients, one |
44 |
tightly integrated and the other plugin-based. Both have optional HTML |
45 |
message support, the latter in the form of a plugin. |
46 |
|
47 |
Now, let's assume we have global USE=html (why the heck we don't have |
48 |
this and instead a dozen of local USE=html, then USE=webkit?!). It is |
49 |
described as something vague like: |
50 |
|
51 |
enable HTML support |
52 |
|
53 |
If I take this USE=html and see it in a mail client, I add 2+2 and get |
54 |
that USE=html enables HTML message support. Now, why the heck I am |
55 |
supposed to find out that the latter mail client instead of this |
56 |
USE=html uses FOO_PLUGINS=htmlviewer? |
57 |
|
58 |
This looks like a double crime to me. First of all, it's introducing |
59 |
a specific, local flag for something that we have a global flag for. |
60 |
Secondly, it's introducing that local flag in a global manner via |
61 |
USE_EXPAND. |
62 |
|
63 |
While we actually avoided having that USE_EXPAND for that specific mail |
64 |
client, there are other cases which are very similar to this. |
65 |
|
66 |
We have three HTTP servers which define USE_EXPANDs for their modules. |
67 |
Each of them uses a completely separate namespace and different names |
68 |
for the *same* features. We have global USE=cgi yet for apache we have |
69 |
to use apache2_modules_cgi. People are reinventing USE=ssl like this |
70 |
as well. |
71 |
|
72 |
And CURL_SSL is a complete disaster. Does supporting 6 different SSL |
73 |
backends (what for?!) justify inventing a global USE_EXPAND? Most of |
74 |
those backends have their local (or even global) flags already. Why do |
75 |
I have to repeat my preference twice? |
76 |
|
77 |
People, get some reason! The major point of having global USE flags is |
78 |
to let user express his preferences *once*. Extensively using |
79 |
USE_EXPAND as a cheap namespace for local flags forces him to re-state |
80 |
those preferences for every single affected package (USE_EXPAND set). |
81 |
|
82 |
-- |
83 |
Best regards, |
84 |
Michał Górny |