From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 6EA461381F3 for ; Thu, 30 May 2013 08:58:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3F0ACE096D; Thu, 30 May 2013 08:58:26 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3A6FCE094E for ; Thu, 30 May 2013 08:58:25 +0000 (UTC) Received: from localhost (178-37-163-206.adsl.inetia.pl [178.37.163.206]) (using SSLv3 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 5808A33E168; Thu, 30 May 2013 08:58:23 +0000 (UTC) Date: Thu, 30 May 2013 10:58:56 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: Gentoo Developer Mailing List Subject: [gentoo-dev] 'Local' USE_EXPAND flags -- aka plugins are not that special Message-ID: <20130530105856.4f97ec8a@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.18; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/=JyvdeY3_083=K=AKjKbmgM"; protocol="application/pgp-signature" X-Archives-Salt: 73bd7b38-ae29-427d-aded-b4b8863e4705 X-Archives-Hash: 85bc5e53f1714999783b27f47d644667 --Sig_/=JyvdeY3_083=K=AKjKbmgM Content-Type: multipart/mixed; boundary="MP_/XEwV2ZBoeztvES1rv0otVNU" --MP_/XEwV2ZBoeztvES1rv0otVNU Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=3D.*${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=3Dhtml (why the heck we don't have this and instead a dozen of local USE=3Dhtml, then USE=3Dwebkit?!). It is described as something vague like: enable HTML support If I take this USE=3Dhtml and see it in a mail client, I add 2+2 and get that USE=3Dhtml enables HTML message support. Now, why the heck I am supposed to find out that the latter mail client instead of this USE=3Dhtml uses FOO_PLUGINS=3Dhtmlviewer? 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=3Dcgi yet for apache we have to use apache2_modules_cgi. People are reinventing USE=3Dssl 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). --=20 Best regards, Micha=B3 G=F3rny --MP_/XEwV2ZBoeztvES1rv0otVNU Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=use-expand.txt 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 --MP_/XEwV2ZBoeztvES1rv0otVNU-- --Sig_/=JyvdeY3_083=K=AKjKbmgM Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJRpxTRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKvlMP/jzUARaAKhqHahsRsRAEPx2O R3WukBsWAiQFfbE+CDYt9rXlNJiyXMKWwd7NbGjw6UoOIdTt7p1tKFTFPzu/Eow2 //iq2+s25uWeAqkhJ1SrcwimhX2187qd+g8guPvueCtUI0Q0tdXdlmEjOKawiAOM bYVeRsD1NVlZJ9bnyn78WxD6LKEzs/qLeFpejxHXp9X+flamQxpZHAn03JVEhp0E lb8uPNIIVo1c/qZzbSCSfpWGUA+ieQhxaKs3qXMDmdTu2YTcu4j61OqEaKYcou6h Ej92pls0VYjvk34QYYsUmrPT/hK1dqnxeS6oOcnNb0GSk29YdH1tUQQFIFRyGg2+ 7S9Ziqs5uQN5WYsGgJhzp/6Vxi2ZMILTrZEy+RZC9Io+IuDr7quknjen0gIPALzc 2ttEZaP2MTxmeGYW/eH0hzAmgBaASAl5bXwDldyUFd3bdc2BmQLdaiAJDnKG+pVX pikJDxRO8yO1Uf/I9cHfA/aKy71IKudfEw5fjJyPDpZmAR81ffYHAH8WxiHEI6wb s0O0UGS0Ktp6OzdAnxx9A2J5ByQICL5EsukQark1KGfSjJvQyMNFmQODJWZYSOeW cNnCG1AB3HHvI+jOrwVBTbwptrVBo1hqj/EB8Lk0uUKHQwIhLbhp9JkjaxiEa0oG 3C4QslqcSUwJaBUww85W =rTyA -----END PGP SIGNATURE----- --Sig_/=JyvdeY3_083=K=AKjKbmgM--