Hello,
I've did a quick statistic of how often USE_EXPAND flags are used.
In order to obtain the results, I have put all known USE_EXPANDs into
${flags[@]} and then did:
for a in "${flags[@]}"; do
echo -n "$a: "
grep -l IUSE=.*${a}_ */* | xargs qatom | cut -d' ' -f1-2 | sort -u
| wc -l done | tee /tmp/use-expand.txt
The result was a table of USE_EXPAND flags with counts of how many
*different* packages declare them in IUSE.
The results are:
package count | n flags
---------------+---------
0 | 3
1 | 24
2 | 4
3-8 | 3
>10 | 11
As you can see, we have *a lot* of USE_EXPAND variables which are only
used by a *single* package. This feels a lot like people are overusing
USE_EXPANDs in place of local USE flags, just to have them prefixed.
And if you take a look at the detailed list (attached for
completeness), you can see that they really do.
And if anyone wondered why it's wrong -- it's wrong because it's much
like declaring global USE flags for a very specific features which are
not only specific to a single package, but are even defined in a way
that they will *never* be suitable to anything else.
Although most of the cases need to be handled separately
and specifically to a particular flag, a common mistake is to introduce
USE_EXPAND every time plugins or modules are involved.
People, plugins are *not* special. There are regular features, just
packaged in a bit different way.
Let's take an example of a mail client. We have two mail clients, one
tightly integrated and the other plugin-based. Both have optional HTML
message support, the latter in the form of a plugin.
Now, let's assume we have global USE=html (why the heck we don't have
this and instead a dozen of local USE=html, then USE=webkit?!). It is
described as something vague like:
enable HTML support
If I take this USE=html and see it in a mail client, I add 2+2 and get
that USE=html enables HTML message support. Now, why the heck I am
supposed to find out that the latter mail client instead of this
USE=html uses FOO_PLUGINS=htmlviewer?
This looks like a double crime to me. First of all, it's introducing
a specific, local flag for something that we have a global flag for.
Secondly, it's introducing that local flag in a global manner via
USE_EXPAND.
While we actually avoided having that USE_EXPAND for that specific mail
client, there are other cases which are very similar to this.
We have three HTTP servers which define USE_EXPANDs for their modules.
Each of them uses a completely separate namespace and different names
for the *same* features. We have global USE=cgi yet for apache we have
to use apache2_modules_cgi. People are reinventing USE=ssl like this
as well.
And CURL_SSL is a complete disaster. Does supporting 6 different SSL
backends (what for?!) justify inventing a global USE_EXPAND? Most of
those backends have their local (or even global) flags already. Why do
I have to repeat my preference twice?
People, get some reason! The major point of having global USE flags is
to let user express his preferences *once*. Extensively using
USE_EXPAND as a cheap namespace for local flags forces him to re-state
those preferences for every single affected package (USE_EXPAND set).
--
Best regards,
Michał Górny
abi_x86: 86 alsa_cards: 2 alsa_pcm_plugins: 0 apache2_modules: 1 apache2_mpms: 1 calligra_features: 1 cameras: 1 crosscompile_opts: 11 curl_ssl: 2 dracut_modules: 1 dvb_cards: 1 elibc: 1300 fftools: 1 foo2zjs_devices: 0 gpsd_protocols: 1 grub_platforms: 1 input_devices: 5 kernel: 136 lcd_devices: 2 libreoffice_extensions: 1 linguas: 363 lirc_devices: 1 misdn_cards: 0 monkeyd_plugins: 1 netbeans_modules: 1 nginx_modules_http: 1 nginx_modules_mail: 1 ofed_drivers: 1 office_implementation: 8 openmpi_fabrics: 1 openmpi_ofed_features: 1 openmpi_rm: 1 php_targets: 64 python_single_target: 127 python_targets: 808 qemu_softmmu_targets: 1 qemu_user_targets: 2 ruby_targets: 559 sane_backends: 1 userland: 19 video_cards: 24 vmware_guest: 1 voicemail_storage: 1 xfce_plugins: 3 xtables_addons: 1
signature.asc
Description: PGP signature
