From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FE1bL-0001bL-Mw for garchives@archives.gentoo.org; Tue, 28 Feb 2006 09:57:04 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1S9sClM009890; Tue, 28 Feb 2006 09:54:12 GMT Received: from smtp.top-hosting.cz (gw.top-hosting.cz [81.0.254.91]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k1S9m1r1026506 for ; Tue, 28 Feb 2006 09:48:01 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.top-hosting.cz (Postfix) with ESMTP id C0F14A886F8 for ; Tue, 28 Feb 2006 10:49:19 +0100 (CET) Received: from smtp.top-hosting.cz ([127.0.0.1]) by localhost (smtp.top-hosting.cz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00495-03-2 for ; Tue, 28 Feb 2006 10:49:15 +0100 (CET) Received: from NOTORCOMP (21.217.broadband4.iol.cz [85.71.217.21]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.top-hosting.cz (Postfix) with ESMTP id 5351FAA9134 for ; Tue, 28 Feb 2006 10:49:15 +0100 (CET) Date: Tue, 28 Feb 2006 10:49:13 +0100 From: Jakub Moc X-Priority: 3 (Normal) Message-ID: <1741768966.20060228104913@gentoo.org> To: Ciaran McCreesh Subject: Re[2]: [gentoo-dev] [RFC] QA Team's role In-Reply-To: <20060227213239.5cf14f0d@snowdrop.home> References: <20060226222217.GB17257@aerie.halcy0n.com> <1140997703.12229.166.camel@demandred.gnqs.org> <20060227003413.GE17257@aerie.halcy0n.com> <20060227170834.075e9388@snowdrop.home> <1141071970.804.19.camel@demandred.gnqs.org> <20060227203709.2a7bff47@snowdrop.home> <20060227204530.GO1516@toucan.gentoo.org> <20060227205445.057a91d9@snowdrop.home> <1141074742.826.35.camel@demandred.gnqs.org> <20060227213239.5cf14f0d@snowdrop.home> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------10916721B3C8AE990" X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at top-hosting.cz X-Spam-Status: No, score=-1.967 tagged_above=-999 required=6 tests=[AWL=0.632, BAYES_00=-2.599] X-Spam-Score: -1.967 X-Spam-Level: X-Archives-Salt: 2ebd570e-7dbb-4140-9ef9-c0d82aa51935 X-Archives-Hash: d9e4c52f09bdf3826cc0e28c8afdac4a ------------10916721B3C8AE990 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =0D=0A27.2.2006, 22:32:39, Ciaran McCreesh wrote: > I quote the official policy: > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3D2&chap= =3D1 >> Occasionally, ebuilds will have conflicting USE flags for >> functionality. Checking for them and returning an error is not a >> viable solution. Instead, you must pick one of the USE flags in >> conflict to favour. One example comes from the msmtp ebuilds. The >> package can use either SSL with GnuTLS, SSL with OpenSSL, or no SSL >> at all. Because GnuTLS is more featureful than OpenSSL, it is >> favoured: > It's a QA violation, and not a feature as you claim. > I find it particularly worrying that you try to pass of blatant policy > violations as a feature. The first step in QA is detecting that there > is a problem. No, that's not a policy document, ebuild policy is documented here: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=3Dprintabl= e&part=3D3&chap=3D1 Moreover, the cited howto is wrong, since it will break built_with_use checks, as explained on the relevant bug and as explained here on mailing list before. The howto also doesn't apply to cases like recode vs. mysql, because that's a completely different functionality, you can't exactly choose which one is better on behalf of the user. So, to sum it up - you can't make up for portage's lack of features by inventing a policy that doesn't work. Once again - until portage can handle USE-based dependencies and until portage can handle conflicting use flags, there's nothing that could be done here. --=20 Best regards, Jakub Moc mailto:jakub@gentoo.org GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=3Dget&search=3D0= xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) ------------10916721B3C8AE990 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFEBByZhxfV/c66PZ4RAnSxAJ46j5qG61UG7ViHoEoRT2EG+/X8nwCfXpD/ NL6S0/8c8quMZAIQ3DEQBYo= =oAAT -----END PGP MESSAGE----- ------------10916721B3C8AE990-- -- gentoo-dev@gentoo.org mailing list