From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1N73y0-0001B0-7q for garchives@archives.gentoo.org; Sun, 08 Nov 2009 09:21:48 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3AC16E09F1; Sun, 8 Nov 2009 09:21:47 +0000 (UTC) Received: from wp165.webpack.hosteurope.de (wp165.webpack.hosteurope.de [80.237.132.172]) by pigeon.gentoo.org (Postfix) with ESMTP id 0B152E09F1 for ; Sun, 8 Nov 2009 09:21:47 +0000 (UTC) Received: from 84-238-114-252.u.parknet.dk ([84.238.114.252] helo=marsupilami.localnet); authenticated by wp165.webpack.hosteurope.de running ExIM with esmtpsa (TLSv1:DES-CBC3-SHA:168) id 1N73xy-0003Ew-2p; Sun, 08 Nov 2009 10:21:46 +0100 From: Thilo Bangert Organization: Gentoo To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] a pragmatic approach to FEATURES [was FEATURES use or misuse?] Date: Sun, 8 Nov 2009 10:21:26 +0100 User-Agent: KMail/1.12.3 (Linux/2.6.31.5; KDE/4.3.3; i686; ; ) References: <200911031648.04090.patrick@gentoo.org> <200911050949.10627.bangert@gentoo.org> <20091105093618.GD25976@hrair> In-Reply-To: <20091105093618.GD25976@hrair> 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; boundary="nextPart4455337.lKWlO1Ol8V"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911081021.29125.bangert@gentoo.org> X-bounce-key: webpack.hosteurope.de;bangert@gentoo.org;1257672107;cde2fa4a; X-Archives-Salt: 5d94c4c7-671e-429d-a8ec-86e01bafd856 X-Archives-Hash: 86858f355d8c8fcdf1bb4c6979fb3e2d --nextPart4455337.lKWlO1Ol8V Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable [snip] > I understand PMS/paludis wishing to duck the vars existance to make it > go away, but I don't think it's a tenuable approach- as you yourself > said above, in trying to do this cleanup you recognized that sometimes > there was no alternative. yes - however, there not being an alternative at the moment does not=20 automatically mean that FEATURES is a good or the best approach. A more=20 clean approach still needs to be proposed.=20 [snip] >=20 > Rather then letting the problem persist, I'd rather see folk take a > look at FEATURES/PMS and identify what needs to be pushed in to take > care of the cases where there is no alternative to 'hasq some-feature > $FEATURES' rather then us just collectively sticking our heads in the > sand. yes - exactly. so which FEATURES are absolutely required in ebuilds /=20 eclasses for which an alternative must be developed? >=20 thanks for your input, BTW --nextPart4455337.lKWlO1Ol8V Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkr2jZgACgkQxRElEoA5AnctqgCgo7aX4VBJADmYqpedBViWHrWQ 5msAoMYtCfdLkiXIGzrNH0+cgZ4XsfPf =C3q5 -----END PGP SIGNATURE----- --nextPart4455337.lKWlO1Ol8V--