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 1LbNtR-0007oz-16 for garchives@archives.gentoo.org; Sun, 22 Feb 2009 23:37:53 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 86FE6E026D; Sun, 22 Feb 2009 23:37:52 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 46A28E026F for ; Sun, 22 Feb 2009 23:37:52 +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 F3A24B6BBF; Sun, 22 Feb 2009 23:37:49 +0000 (UTC) Message-ID: <49A1E1CB.1000806@gentoo.org> Date: Mon, 23 Feb 2009 00:37:47 +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-council@lists.gentoo.org MIME-Version: 1.0 To: Ryan Hill CC: gentoo-council@gentoo.org Subject: Re: [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> In-Reply-To: <20090222171658.278ae167@halo.dirtyepic.sk.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: e81ae59e-ed9e-449f-a793-e158873bc14c X-Archives-Hash: e5905773d4b6568c20f4f830ba68adc5 Ryan Hill wrote: > On Fri, 20 Feb 2009 00:11:32 +0300 > Peter Volkov wrote: > >> That said, technically there are other solutions for this problem, >> e.g. 1) it is possible to read one line of defined format from any >> file 2) it is possible to make eapi inside ebuild name >> (foo-1.0-eapi2.ebuild), but not as extension. Any solution, even >> breaking compatibility solution, we could already start using if we >> had forgotten about GLEP 55 long time ago... > > I really don't understand why foo-0.1.eapi3.ebuild is considered an > acceptable solution and foo-0.1.ebuild.eapi3 is not. I guess that principle of the least surprise counts there. > They have the same advantages, arguments about aesthetics aside, and > seem to be a much cleaner solution than any other that has been > proposed. Using either manifests and or switch sync path is even less invasive if you consider that point raised against the proposal to switch extensions every time something changes in the ebuild format is that is misleading. > But the former has one distinct disadvantage that the latter > does not: any currently released version of portage does not work > correctly with ebuilds having version suffixes it does not recognize. > For example, you cannot currently create a Manifest in a package > directory containing a file named package-1.0.eapi3.ebuild. Portage should warn/die if stray files are present. So the whole thing looks to me as a way to harness a bug. > We can modify portage, of course, to recognize this suffix, and then > wait long enough for that release to trickle down. But later, if we > want to add another suffix, -scm perhaps, or something we > haven't considered yet, we again have to go through the same process. I > thought the reason we introduced EAPI was to free us from this. As stated before this eapi had been considered a ugly solution looking for problems to solve. > With a format such as .ebuild.eapiX we would avoid these issues. Using manifest to have portage validate/invalidate ebuilds works as well and is completely transparent. > Portage (without any modifications) will not recognize these files as > ebuilds (which is exactly the behaviour we want if it doesn't > understand the EAPI), so the format of the version string is moot. We > could introduce -scm (or whatever) in EAPI X, and be able to use it > immediately. > I'm sorry, but until you come up with a better reason than "it's > tradition", I'm afraid this will continue to be submitted indefinitely. > You will have to provide technical objections why this approach is > unacceptable before anyone can come up with something that is. Usually in order to get something changed is the burden of the proponents make it worthy for everybody else. Moreover if the change causes any annoyance, its usefulness has to be considered superior to the damage. We got people that annoyed about this proposal that they stated they'll quit if it is passed. > Here is an example, to get you started: > If a Manifest is generated using a portage version that supports an > EAPI and recognizes a package atom containing a version suffix that > was added in that EAPI as an ebuild and thus categorizes it as EBUILD in > the Manifest, do portage versions that do not support the EAPI have > trouble when they see the entry marked EBUILD for a package atom they > think is invalid? Manifest2 is backward compatible to manifest1 by ignoring lines it couldn't parse, so if we have portage embed the eapi information there we'd archive the same result being completely transparent. This proposal is in the migration-paths document, why we shouldn't use a less invasive approach, that is using pretty much the same principle but doesn't have the shortcoming the extension rename ? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero