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 1LbQLd-0006El-6v for garchives@archives.gentoo.org; Mon, 23 Feb 2009 02:15:09 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D9B14E029D; Mon, 23 Feb 2009 02:15:07 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 8F8A2E029B; Mon, 23 Feb 2009 02:15:07 +0000 (UTC) Received: from [192.168.0.91] (unknown [151.57.3.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id DAF8BB6BDB; Mon, 23 Feb 2009 02:15:05 +0000 (UTC) Message-ID: <49A206A7.3050604@gentoo.org> Date: Mon, 23 Feb 2009 03:15:03 +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] 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> In-Reply-To: <20090222234800.29d64b8d@snowcone> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 48de937c-e18a-4ffb-8df1-d2db45ad4c2d X-Archives-Hash: ec66c66886a5192fd49260422f05cd0d Ciaran McCreesh wrote: > Because your proposal addresses none of the underlying problems which > GLEP 55 was created to solve. As said long ago the glep doesn't tell enough: "The current way of specifying the EAPI in ebuilds is flawed. In order to get the EAPI the package manager needs to source the ebuild, which itself needs the EAPI in the first place. Otherwise it imposes a serious limitation, namely every ebuild, using any of the future EAPIs, will have to be source'able by old package managers and hence there is no way to do any of the following: * Change the behaviour of inherit in any way (for example, to extend or change eclass functionality). * Add new global scope functions in any sane way. * Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54" 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... Now problems: 1- the cache could get a non compatible change 2- the user triggers a metadata cache regeneration -> the ebuild is sourced -> portage could fail or do something unpredictable 3- overlays do not provide metadata cache 4- A package manager different from portage do not use the provided cache. Solutions: 1- move the incompatible cache out of ancient portage scope (like in a separate directory) 2- The user will get unpredictable behavior, but portage tell you when upgrading is needed... 3- you'd have to disable them 4- unsupported. Apparently for this side we don't have much to do if we get a valid cache. Ebuilds have to be added to portage so here the workflow for the developer: - new ebuild is sourced - cache is generated - manifest is built 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 - then behave as defined by 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. This will solve the issue for the developer. 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. The fact the glep itself is too much terse doesn't help acknowledging the problems it aims to solve and the fact it fails to state actual issues that may need a solution doesn't make it worth the effort and disruption it would lead. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero