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 159B61386F3 for ; Thu, 13 Aug 2015 08:24:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BC82A1421F; Thu, 13 Aug 2015 08:24:21 +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 9EE21E0867 for ; Thu, 13 Aug 2015 08:24:20 +0000 (UTC) Received: from [IPv6:2001:470:1f09:1501::2] (work.pinkbyte.ru [IPv6:2001:470:1f09:1501::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pinkbyte) by smtp.gentoo.org (Postfix) with ESMTPSA id 87489340861 for ; Thu, 13 Aug 2015 08:24:19 +0000 (UTC) Message-ID: <55CC542C.1070105@gentoo.org> Date: Thu, 13 Aug 2015 11:24:12 +0300 From: Sergey Popov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: useflag policies References: <55C7AC24.2040503@gentoo.org> <55C9CA32.3060300@gentoo.org> <55C9F189.10102@gentoo.org> <55CA0D39.1040306@gentoo.org> In-Reply-To: <55CA0D39.1040306@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SosirAEX1GclMfclgl4RJDme8Bt7Ql24F" X-Archives-Salt: 08b41823-55b6-47b3-a587-b9a03669227d X-Archives-Hash: 89b7f06aaf807ee6d8a48ff92920861a This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SosirAEX1GclMfclgl4RJDme8Bt7Ql24F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 11.08.2015 17:56, Ian Stakenvicius =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On 11/08/15 08:58 AM, Sergey Popov wrote: >> 11.08.2015 15:30, Michael Palimaka =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>> On 11/08/15 20:10, Sergey Popov wrote: >>>> Err, i have read the whole thread and still does not get a >>>> point, why i am wrong. >>> >>> You clearly have not. The reasoning behind Qt team's policy is >>> described on the page and has been reiterated on this list. You >>> are undermining what little confidence there is in the QA team by >>> making decisions with no consultation about problems you do not >>> understand. >>> >>>> It's old battle like we have beforce with "gtk" meaning "any >>>> versions of GTK flag". This behaviour should be killed with >>>> fire. >>>> >>>> Let's me reiterate some of the cases: >>>> >>>> 1. Package can be build without Qt GUI at all, but either Qt4 >>>> or Qt5 can be chosen, but not both. >>>> >>>> Fix this with REQUIRED_USE, do not enable any of Qt flags by >>>> default >>> >>> Problem: this requires manual intervention if the user has both >>> qt4 and qt5 USE flags enabled. >>> >=20 >> User choice of using USE flags is NOT a problem >=20 >>>> >>>> 2. Package can not be build without Qt GUI - either Qt4 or Qt5 >>>> is required, but not both >>>> >>>> Same thing here, different REQUIRED_USE operator. But - enable >>>> one of the flags by default to ease life of users. >>> >>> Problem: this requires manual intervention if the user has both >>> qt4 and qt5 USE flags enabled. >=20 >> Same here >=20 >>>> >>>> 3. Package can be build with Qt4 or Qt5 or both AT THE SAME >>>> TIME(if such package even exists?) >>>> >>>> Do not use REQUIRED_USE here, not needed. >>>> >>>> Now, please tell me, where am i wrong? >>>> >>> >>> The problem is manual intervention is required if the user has >>> both qt4 and qt5 USE flags enabled - and this is a common >>> configuration. It is not acceptable to make a user manually add >>> numerous package.use entries when all they want to do is install >>> KDE. >=20 >> And here >=20 >>> I agree Qt's policy is not a perfect solution, but in the absence >>> of some feature allowing a preference to be set when there is a >>> conflict it's the best we've got. >>> >=20 >> If you want to go this way, then please provide helper functions >> in eclasses to set dependencies properly for all common use cases. >> That will ease life both of developers and users. >=20 >=20 > Why do you need this? >=20 > #1, if you really want RDEPEND to only include the deps the package > will actually use, then you do this: >=20 > old: >=20 > qt5? ( list of qt5 atoms ) > qt4? ( list of qt4 atoms ) >=20 > ..to new: >=20 > qt5? ( list of qt5 atoms ) > !qt5? ( > qt4? ( list of qt4 atoms ) > ) >=20 >=20 > BUT I would advise against this. If a user has specified both qt4 and > qt5 in USE, then I see no problem with the VDB having both qt4 and qt5 > atoms listed as dependencies. End-users that want a clean VDB can > just make sure they only enable one flag, but end-users that don't > care will have packages that just work. >=20 great, in that case emerge --depclean becomes completely useless, because of unneeded vdb deps. Those DEPENDs that i have provided was at least consistent in terms of dependencies(that does not mean that they are not ugly, though) >> Leaving constructing of dependencies to developers in all cases >> will cause only pain in your solution. >=20 > It really wont, see above. At minimum, it's barely any more work than > it is with a REQUIRED_USE based solution. >=20 I repeat that i said earlier: if this voodoo magic will be hidden in some eclass - it is fine. If developers will be forced to add this depstring over and over again - it will be PITA. --=20 Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead --SosirAEX1GclMfclgl4RJDme8Bt7Ql24F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVzFQsAAoJECo/aRed92672fIH/0gs6rDVUzyYOzhhB2/i9apA o84JJF0wXK50ArkHxGDYQrcbU+esOU3cncElQCUdJq/igJXgB7w1lKMiOunb1cVL 4JfKlNkSWtFcwlYGq4sfvXKp24rxTS21pk/di2HadKtyJdq7YtHAIIFUGlO8PJEv AyIMC/y/fpXH0fRzQw73vf6gufuire1GyxKGYKHtTWxHktSGYSlIUNgYOl1OFHcR FAJIW+EL2N/LEq8QWdCVCNcOV14IjzmkQjuxhhEBc/7EBcQVt1pmtBA7z/6m6Tvn gJ3RdvRmIxBBC7s7GZYkn8NAb18SOIQdy5hseY097G/bibOpKpMTup8J+aXU0P4= =zl08 -----END PGP SIGNATURE----- --SosirAEX1GclMfclgl4RJDme8Bt7Ql24F--