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 9EDC81395E1 for ; Sun, 2 Aug 2015 17:34:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 74DAB1405A; Sun, 2 Aug 2015 17:34:02 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7186914055 for ; Sun, 2 Aug 2015 17:34:01 +0000 (UTC) Received: from localhost (sloan0.ut.mephi.ru [85.143.112.33]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bircoph) by smtp.gentoo.org (Postfix) with ESMTPSA id 3B37F34082B for ; Sun, 2 Aug 2015 17:34:00 +0000 (UTC) Date: Sun, 2 Aug 2015 20:33:54 +0300 From: Andrew Savchenko To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] useflag policies Message-Id: <20150802203354.1f6ba9254be090487ec48380@gentoo.org> In-Reply-To: References: X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; i686-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; protocol="application/pgp-signature"; micalg="PGP-SHA512"; boundary="Signature=_Sun__2_Aug_2015_20_33_54_+0300_l1ELPalDpnYMhIlL" X-Archives-Salt: 8018c22e-b9f3-44d9-9fa4-92072f6045d6 X-Archives-Hash: 7769d070241964e6b76f8d68f5362d13 --Signature=_Sun__2_Aug_2015_20_33_54_+0300_l1ELPalDpnYMhIlL Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 3 Aug 2015 00:34:51 +0800 Ben de Groot wrote: > Recently some team members of the Qt project have adopted these ebuild > policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies >=20 > I have an issue with the policy adopted under "Requires one of two Qt > versions". In my opinion, in the case where a package offers a choice > between qt4 or qt5, we should express this in explicit useflags This is what the policy does: "Implement both qt4 and qt5 USE flags" > and a > REQUIRED_USE=3D"^^ ( qt4 qt5 )". This offers the user the clearest choice. This will create insane amount of blockers if users have both flags in make.conf (and this is a common scenario). > Other developers state that users are not interested in such implementati= on > details, or that forced choice through REQUIRED_USE is too much of a > hassle. This results in current ebuilds such as quassel to not make it > clear that qt4 is an option. >=20 > This goes against the principle of least surprise, as well as against QA > recommendations. I would like to hear specifically from QA about how we > should proceed, but comments from the wider developer community are also > welcome. =20 As far as I understand this is done to simplify user's experiense: usually people set both USE=3D"qt4 qt5" in global make.conf, because they want qt in the first place. This policy will allow to USE both qt versions whichever is available preferring newer one. Quite reasonable approach. Alternatives (^^() and ??()) will require micromanagement (e.g. pagkage.use.conf) for dozens if not hundreds of packages for no good reason. If someone still needs to override such policy (e.g. to use qt4 when both are available), this can be done by per-package configuration. My idea is that packages should be fully controllable, but choises of default behaviour should be done so, that in most cases micromanagement will not be necessary. I like this qt policy and I'm not sure if it violates any current rule. But even in such case this rule should be fixed. Moreover, this problem is not limited for qt: we have exactly the same issue with gtk2 vs gtk3 and probably some other technologies. Of course in theory it is possible to build package with two sets of binaries supporting both qt4 and qt5, but I see little practical need for that. So I propose to add somewhere to devmanual/policies the following recommendation: "If package supports several versions of the same technology (e.g. qt4 and qt5) and more than one is enabled by USE flags, ebuild should prefer the later one (in terms of technology generation).". Best regards, Andrew Savchenko --Signature=_Sun__2_Aug_2015_20_33_54_+0300_l1ELPalDpnYMhIlL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVvlSCAAoJEPZTWjO6HuSNeIkP/jsm6xPkewL8z9W68YmuWK3C m9nVhcNAi6GWzRbkuknGCeIB+N1LjY9J1dkUjEj1ENUlgUXIcohsuFh7/kRabZAh na9tu5tAezuVXuROxYDj3wwuG/2Ih2qvLRMQCRFQcYdiqkO07k5FC6jB6YAZXzcn g8Q1GhNL1Cb+hiFDcHeqididQbliBPde9VbiYwkEmVtfisZKk/bGgYTNyI7SgLZQ GPtBWjOe8+tom/nvr6kSSBHs/MpXsmpMc6VVG4U1ZXgGF+LgQRnIIaIzFZeLNPJo IQKZNPNk49Z91//16ha7KEx0TUOMtT6vMEYH3HbRU4enKBNG0iDpdDwXeDmrI+vG njtwoh6KnvM1nkSE5Inn9AyijQyRkmmczBRMPzEDDAdLFsi8HXnqQJ8WrT3qUKLJ 3ZWj5X6qwarISqTtsTPenfNX3fbF5Cy92Jtp77e2TOYHm6LMSExb4FY2xiymULDQ ooUcbcxbb/ytOowVsgb8Cwwmnx6rrSB6r5q1f8qsCpfIssJicgJWSLpeAusfhCoj fz63ySLFLNyh7FEShUd0Alm14RNXQK+CIUK/EiNpvhe++pwzHQ1ZKh1vHS8MC9q6 5AiNsm+KHcBGNCV0ryTQppDJB+oREf41xPpi4RmErtGJEyeLibOAILOovECcVeD5 0ILbyq5y2r8nbfQatk4Z =9qVN -----END PGP SIGNATURE----- --Signature=_Sun__2_Aug_2015_20_33_54_+0300_l1ELPalDpnYMhIlL--