From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LQ3M3-0000Bt-Bq for garchives@archives.gentoo.org; Thu, 22 Jan 2009 17:28:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C47B5E0738; Thu, 22 Jan 2009 17:28:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 8EC20E0738 for ; Thu, 22 Jan 2009 17:28:32 +0000 (UTC) Received: from gentoo.org (xray.science.oregonstate.edu [128.193.220.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 04814646C8 for ; Thu, 22 Jan 2009 17:28:32 +0000 (UTC) Date: Thu, 22 Jan 2009 09:28:31 -0800 From: Donnie Berkholz To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22 Message-ID: <20090122172831.GB20446@comet> References: <20090121233526.GA15870@comet> <4977E7EC.8070007@gentoo.org> <20090122033805.GA9101@hermes> <4977F1B5.3080608@gentoo.org> <20090122161134.7c27ed3e@snowcone> <20090122165623.GA20446@comet> <20090122170233.1dab8ef7@snowcone> 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="JYK4vJDZwFMowpUq" Content-Disposition: inline In-Reply-To: <20090122170233.1dab8ef7@snowcone> User-Agent: Mutt/1.5.18 (2008-05-17) X-Archives-Salt: 3c30f512-514e-429d-a9cc-5234eec1af14 X-Archives-Hash: 5da8e52993b748f75d070132b5817e71 --JYK4vJDZwFMowpUq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 17:02 Thu 22 Jan , Ciaran McCreesh wrote: > On Thu, 22 Jan 2009 08:56:23 -0800 > Donnie Berkholz wrote: > > Can this be fixed by adding bash dependencies to things using new=20 > > features? As long as we keep them out of the build path of bash, > > things ought to work. >=20 > Only if you're guaranteed bash 3.1 on boxes that do metadata > generation. Which means it won't work for overlays. I'm not an expert on metadata generation, so please tell me if I'm wrong=20 here. Most if not all overlays don't ship pregenerated metadata, which=20 means users have to generate it locally. Without doing so, they cannot=20 install anything from that overlay that uses bash features they lack.=20 They can still install things from that overlay that don't use the new=20 bash features. Consequently, packages in overlays using new bash features won't work=20 till you upgrade your bash. They also won't be able to give you a good=20 error about how to fix it, because you can't guarantee that you'll be=20 able to parse the ebuild/eclass as far as the bash dependency. I guess a GLEP 42 news item would sort of work, but I really wish we had=20 tree dependencies. Another option would be to make overlay maintainers=20 generate their own metadata. > > Then we could add a repoman check for new features, if we wanted. >=20 > Can't do that unless you write a feature-complete bash parser and > pretend-execute every possible path an ebuild can take... We're getting into pretty weird territory here -- if you had slotted=20 bash versions, you could do bash-3.0 -n foo.ebuild, bash-3.1 -n=20 foo.ebuild, etc. --=20 Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com --JYK4vJDZwFMowpUq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkl4rL8ACgkQXVaO67S1rtvNDQCg3h5INUaYHSmnrw0iffoaBaaH r/0An22aLVW3s85jVn4isTlIiSjj93fV =+Zho -----END PGP SIGNATURE----- --JYK4vJDZwFMowpUq--