Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: Gentoo Developer Mailing List <gentoo-dev@l.g.o>
Subject: [gentoo-dev] 'Local' USE_EXPAND flags -- aka plugins are not that special
Date: Thu, 30 May 2013 08:58:30
Message-Id: 20130530105856.4f97ec8a@gentoo.org
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

Attachments

File name MIME type
use-expand.txt text/plain
signature.asc application/pgp-signature

Replies