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 1N5uW6-0005gV-Ld for garchives@archives.gentoo.org; Thu, 05 Nov 2009 05:04:14 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A930AE09EC; Thu, 5 Nov 2009 05:04:13 +0000 (UTC) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by pigeon.gentoo.org (Postfix) with ESMTP id 8DA90E09E5 for ; Thu, 5 Nov 2009 05:04:13 +0000 (UTC) Received: by gxk24 with SMTP id 24so7095328gxk.6 for ; Wed, 04 Nov 2009 21:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=KC1FgJ75bIP8C8L1kj+i+568Dd1wSiVW/VjUtdhDdBg=; b=ZANMfHEgpYX3qSkZwR7NcHTegEMSlW4AIZUzEDdpuiD5cCP/Gt7/IjWarj9VlySjq7 Io5CPq1+PZESqN6LE9jZUJVGRjU1NOMbQVFl5gkWx2oblrHEBfFqHVacz1Har49Buwrt hFfHCWR/J2xeGLZzzJJIH+OX8jFg/FjjCdpck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=m0GNnbMkaEwPC1WE22jrnqEIDcpv1zX49XppY8gTd4WbiOxrCuOS2ZUwV559SSx+hr 0ORefcF9maygUEDPMrGHfUbYKsUX+DhZp9ydpd9g19U1JffRZhDHarGSi4VTViA8C2/U +nW1hnxphL95TqR+2fwcd6dcuXUqbZA2tfQyU= Received: by 10.91.171.4 with SMTP id y4mr4948481ago.116.1257397453157; Wed, 04 Nov 2009 21:04:13 -0800 (PST) Received: from smtp.gmail.com (c-98-210-130-131.hsd1.ca.comcast.net [98.210.130.131]) by mx.google.com with ESMTPS id 7sm811518yxg.68.2009.11.04.21.04.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Nov 2009 21:04:11 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Wed, 04 Nov 2009 21:04:01 -0800 Date: Wed, 4 Nov 2009 21:04:01 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: FEATURES use or misuse? Message-ID: <20091105050401.GC25976@hrair> References: <200911031648.04090.patrick@gentoo.org> <1257372724.5846.26.camel@lillen.dodi> 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-sha1; protocol="application/pgp-signature"; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline In-Reply-To: <1257372724.5846.26.camel@lillen.dodi> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: fd377029-b4c6-4a92-83e8-43065fe75c7b X-Archives-Hash: bc348313e7d9fa0fef52cdef8be5310b --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 04, 2009 at 11:12:05PM +0100, Peter Hjalmarsson wrote: > tis 2009-11-03 klockan 16:48 +0100 skrev Patrick Lauer: > > Hi there, > >=20 > > All of these bugs were for the use of the FEATURES variable in ebuilds,= which=20 > > is a very convenient thing to work around issues.=20 > > For example known failures with FEATURE=3D"distcc" or funky things like= test=20 > > failures with FEATURES=3D"userpriv" and so on. All other methods of exp= ressing=20 > > that are much more verbose and inherently sucky. >=20 > I ask myself if what we really want is many different and strange > approaches to handle FEATURES? > Would it not be better to actually expand some eclasses to be able to > say something about your build environment? This is a *really* bad approach- pkgcore/paludis have supported=20 standalone repositories basically from their inception, portage (via=20 repos.conf) has developed equivalent support, and from the looks of it=20 is moving towards such capabilities. What this means is that eclasses aren't automatically mashed together=20 across all trees and shared. Meaning each repository would have to=20 carry those eclasses, or require that they always be slaved against a=20 specific repository carrying said eclasses (again, bad mojo). The code duplication there is annoying, but the potential range of=20 screwups this can lead to is even worse. Further, via proper=20 environment saving/restoration for installed pkgs/binpkgs, this means=20 that one screwed up FEATURES detection (or that things have changed=20 since then and a new check is required) lives on forever, no=20 possibility of being updated/fixed in the env dump. Shorter version, eclasses are a fun idea at first until you dig in and=20 realize they'll blow your leg off for things like this. If it's any consolation, I proposed moving large chunks of eapi0=20 (prior to eapi existing) into the tree- the idea died off for the same=20 reasons your "FEATURE awareness in eclasses" must die off. ~harring --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkryXMEACgkQsiLx3HvNzgfy1wCgtDgOTQ9+x0PVJzDxS+4oq6lK 7GsAn18QutKehmm9zOctTklh+wpAbAqz =kzPA -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes--