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 1LbbJ6-0008Qu-5e for garchives@archives.gentoo.org; Mon, 23 Feb 2009 13:57:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E9662E0464; Mon, 23 Feb 2009 13:57:14 +0000 (UTC) Received: from mail-bw0-f157.google.com (mail-bw0-f157.google.com [209.85.218.157]) by pigeon.gentoo.org (Postfix) with ESMTP id 59FAFE0456; Mon, 23 Feb 2009 13:57:14 +0000 (UTC) Received: by bwz1 with SMTP id 1so4701923bwz.10 for ; Mon, 23 Feb 2009 05:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=r3Hws8GQW6FzYjCdPu2Mx+Blo4hDnonyVZ9hY9p6BM8=; b=KZeEpMUlZG4+qpcOg2owU1wn4EUpzR/VNMamIlqC/xU/RNv6oe1iqttML2egLMbJgV KE8lFOKKsaA6hg/4SAq5NZizTW1xx9o5PWoye0OHHjErp5BBpApP8vNicWDp2H+V2pzc ZlgMDIG5pvPn90znnkDhIRDFK+y1v0cmUGy10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=Xwp1q//XI3l9bhd/FeYjBO46ZIL+5WHEzM2xiqFDmK835AdOLktyUjha3l0Io2nP9+ 5k/Erql+fy14Wd1bP7sLxLdzI1edx/9+p2BrAPAz1XzF70BO5zgbVzb+y97mJLzqNaCY 59xJUTpplZIQBrpfso3iBqwS4Ew0ddNEvFuLI= Received: by 10.103.213.10 with SMTP id p10mr3321046muq.17.1235397433362; Mon, 23 Feb 2009 05:57:13 -0800 (PST) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id e34sm15971378ugd.20.2009.02.23.05.57.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 05:57:12 -0800 (PST) Date: Mon, 23 Feb 2009 13:57:02 +0000 From: Ciaran McCreesh To: Luca Barbato Cc: gentoo-council@lists.gentoo.org, gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Message-ID: <20090223135702.3d593d3f@snowcone> In-Reply-To: <49A206A7.3050604@gentoo.org> References: <1234257125.18160.2016.camel@localhost> <1234450419.20950.2.camel@localhost> <20090212160045.GB3642@comet> <20090212161644.GD3642@comet> <20090212162103.256b003f@snowcone> <20090212171055.GA3652@comet> <20090212172109.778fb268@snowcone> <20090212173743.GD3652@comet> <20090212180350.0d9a9df5@snowcone> <1235037961.13198.779.camel@localhost> <20090219125124.33eaa66c@snowcone> <1235077892.13198.1923.camel@localhost> <20090222171658.278ae167@halo.dirtyepic.sk.ca> <49A1E1CB.1000806@gentoo.org> <20090222234800.29d64b8d@snowcone> <49A206A7.3050604@gentoo.org> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64-pc-linux-gnu) 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="Sig_/y_iB1VbQAx1gE=E7.T6o4xT"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: c0000428-faf0-4de3-ac23-6182f5a8e33e X-Archives-Hash: faf8bcaa956a11657ceed65bffcd5420 --Sig_/y_iB1VbQAx1gE=E7.T6o4xT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 23 Feb 2009 03:15:03 +0100 Luca Barbato wrote: > Let's try to start with a common workflow for the user: > - an user with an ancient version of portage syncs > - it requires a package > - it looks at the cache ($portdir/metadata/cache/) > - picks the best entry from the ones showing an eapi it understands > - keeps going. >=20 > Apparently we do not have any issue... ...assuming the metadata cache is valid. That isn't always the case. > 2- The user will get unpredictable behavior, but portage tell you > when upgrading is needed... Not if the version you'd need to do metadata generation is ~arch it doesn't. > 3- you'd have to disable them Yes, tell everyone to disable all the overlays that make use of a few features only in ~arch package managers... That'll work... > In this case we have a problem if the source step is a single one,=20 > portage won't know in advance how to behave. >=20 > So the first step has to be split in two: > - first portage discovers which is the eapi version ...which it can't do, because it doesn't know the EAPI. > The problem is that right now sourcing is done by having an > instructed bash. So the simplest way to get the first step done is > parsing the ebuild file with something different like file(1) and > then instruct bash and do the parsing. file(1) can't parse ebuilds. Only an ebuild implementation can parse ebuilds, and only if it already knows the EAPI. > What is proposed in glep-55 seems to aim to solve both issues at the=20 > same time (it isn't stated) by switching file extension every time > the eapi is changed. This is slightly against the principle of the > least surprise and apparently is disliked by enough people to lead > the situation to be discussed in the council. There's no surprise at all. It's extremely clear. --=20 Ciaran McCreesh --Sig_/y_iB1VbQAx1gE=E7.T6o4xT Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmiqzAACgkQ96zL6DUtXhGU+QCbBJjKhbJboOAa/XJZlfTNevis HRAAn1O+d0nvUCke6Xrowct1XwMXLA4X =iwE0 -----END PGP SIGNATURE----- --Sig_/y_iB1VbQAx1gE=E7.T6o4xT--