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 1Lbc4l-0005aW-6T for garchives@archives.gentoo.org; Mon, 23 Feb 2009 14:46:31 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B4A52E0487; Mon, 23 Feb 2009 14:46:27 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 7463CE0486; Mon, 23 Feb 2009 14:46:27 +0000 (UTC) Received: from [192.168.0.91] (83-103-77-215.ip.fastwebnet.it [83.103.77.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id E2BFAB5A4C; Mon, 23 Feb 2009 14:46:25 +0000 (UTC) Message-ID: <49A2B6C0.1070900@gentoo.org> Date: Mon, 23 Feb 2009 15:46:24 +0100 From: Luca Barbato User-Agent: Thunderbird 2.0.0.18 (X11/20081205) 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 To: Ciaran McCreesh 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) 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> <20090223135702.3d593d3f@snowcone> In-Reply-To: <20090223135702.3d593d3f@snowcone> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 77ea8ac3-96fb-4526-bf45-dce098a0b826 X-Archives-Hash: 09d9d33ef89fe8840cf9b1eb9ba94a0d Ciaran McCreesh wrote: > 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. >> >> Apparently we do not have any issue... > > ...assuming the metadata cache is valid. That isn't always the case. When it isn't? >> 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... disable overlays to UPGRADE to the new portage. Not rocket science... >> In this case we have a problem if the source step is a single one, >> portage won't know in advance how to behave. >> >> 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. If you are generating the cache you must have a way to know it... >> 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. file parses quite well avi and mov, ebuild will be anytime more complex than that right? Anyway it isn't a problem since the version of portage doing the work is supposed to be up to date, if isn't it will be updated first using the normal user workflow that has already been covered by the cache. > Only an ebuild implementation can parse > ebuilds, and only if it already knows the EAPI. That is always the case since you are adding an ebuild and you are supposed to have an up to date portage in order to do that. >> What is proposed in glep-55 seems to aim to solve both issues at the >> 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. Not that much. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero