From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
	by finch.gentoo.org with esmtp (Exim 4.60)
	(envelope-from <gentoo-dev+bounces-36509-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1MDeDK-0000K2-Mx
	for garchives@archives.gentoo.org; Mon, 08 Jun 2009 12:44:34 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 03217E02CD;
	Mon,  8 Jun 2009 12:44:33 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
	by pigeon.gentoo.org (Postfix) with ESMTP id B9C78E02CD
	for <gentoo-dev@lists.gentoo.org>; Mon,  8 Jun 2009 12:44:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
	by smtp.gentoo.org (Postfix) with ESMTP id 59F5E64C1B
	for <gentoo-dev@lists.gentoo.org>; Mon,  8 Jun 2009 12:44:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at gentoo.org
X-Spam-Score: -1.495
X-Spam-Level: 
X-Spam-Status: No, score=-1.495 required=5.5 tests=[AWL=0.037,
	BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067]
Received: from smtp.gentoo.org ([127.0.0.1])
	by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id S33EUEnygJyW for <gentoo-dev@lists.gentoo.org>;
	Mon,  8 Jun 2009 12:44:25 +0000 (UTC)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp.gentoo.org (Postfix) with ESMTP id BC69365326
	for <gentoo-dev@gentoo.org>; Mon,  8 Jun 2009 12:44:23 +0000 (UTC)
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1MDeD5-0005Az-0Q
	for gentoo-dev@gentoo.org; Mon, 08 Jun 2009 12:44:19 +0000
Received: from 91.85.167.206 ([91.85.167.206])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <gentoo-dev@gentoo.org>; Mon, 08 Jun 2009 12:44:19 +0000
Received: from slong by 91.85.167.206 with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <gentoo-dev@gentoo.org>; Mon, 08 Jun 2009 12:44:19 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-dev@lists.gentoo.org
From:  Steven J Long <slong@rathaus.eclipse.co.uk>
Subject: [gentoo-dev]  Re: Re: GLEP 55 Version 2
Date:  Mon, 08 Jun 2009 13:42:44 +0100
Organization:  Friendly-Coders
Message-ID:  <5204115.WX2jVEVibr@news.friendly-coders.info>
References:  <18987.35220.808040.666422@a1ihome1.kph.uni-mainz.de> <1244383925.3671.1@NeddySeagoon>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7Bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: 91.85.167.206
Sender: news <news@ger.gmane.org>
X-Archives-Salt: 102c2a87-95ca-4b8d-963a-7e1f0ef04f39
X-Archives-Hash: 1d35ae832bbe94a7fccb3fae788df052

Roy Bamford wrote:

> On 2009.06.07 10:34, Ulrich Mueller wrote:
>> >>>>> On Sun, 07 Jun 2009, Steven J Long wrote:
>> 
>> > I'd just like to know what the implications would be for users if
>> we
>> > kept the .ebuild extension, and a new PMS were rolled out stating
>> > that the mangler were allowed to find the EAPI without sourcing
>> (and
>> > giving the restrictions) once portage 2.2 was stable, or the
>> ability
>> > to handle this backported to 2.1.6, and issued in a release?
>> 
>> Even if we do only a one-time change of the file extension, can we
>> ever get rid of the old extension? Or are we then stuck with two
>> extensions in the tree until the end of time?
>> 
>> Let's assume for the moment that we change from ".ebuild" to ".eb".
>> Then we obviously cannot change all ebuilds in the tree to ".eb",
>> otherwise old Portage versions would see an empty tree and there
>> would
>> be no upgrade path.
>> 
>> Or am I missing something?
>>
Sounds about right

> 
> First, lets be clear that the upgrade path related problems are driven
> by the EAPI change, not the .ebuild to .eb change.  That serves only to
> allow the new EAPI to be introduced immedately and hide the change from
> older package managers
>
<snip> 
> To keep an upgrade path, package managers and their dependencies need
> to use EAPI 0, 1 or 2. (EAPI 3 is not yet out) How far back should the
> upgrade path extend?
>
Well given that EAPI 3 is not out, and that bash-4 is not even stable
(and if anyone thinks we can rely on bash-4 in the next 6 months, they
didn't learn anything from bash-3 imo) this sounds like it's a fair
distance away. From discussion with Harring, EAPIs were not meant to
come out very often; iirc he said something like maybe once a year.

I concur with Duncan on a year, as you know. I appreciate you feel it
should be longer, and am happy to go with whatever the consensus is.

> As you suggest, even with .ebuild to .eb change.its not a clean break
> with the past but would happen over time, with ebuilds for new package
> versions being migrated to the new format. For example we would
> have
> foo-2.1-r1.ebuild
> foo-3.0.eb
> portage-2.3.ebuild
> portage-3.0.eb
>
yuck.

> Portage-2.3 will understand the later EAPI but will itself, use only
> EAPI, 0, 1 or 2.
>
Just to be clear: portage-2.2 and later will be fine with any EAPI, with
no change to any ebuilds, nor any new extension being needed. The
change can easily be backported to 2.1.6, tho I suspect 2.2 will be
stable fairly soon.
 
> Thats just portage. The same reasoning applies to any other package
> manager and there are at least three. This begs the question of how
> friendly do we want to be to derivitive distros that use our tree but
> their own package manager?
>
As friendly as we can be without hobbling our own development. Most of
them appear to be fairly collaborative with Gentoo in any case.

> Upgrade path issues need to be addressed in the GLEP. I will add
> something like the above in the next version.
>
Wrt transitioning, can the eapi (PMS 5.2.2) and deprecated (5.2.3) files
not be of use? I seem to recall the change from 2007.1 to 2008.0 for
example; anyone using a deprecated profile can expect a massive warning
the next time they try to do anything after sync'ing.

Thanks again for your work; I appreciate that your time is valuable.

Regards,
Steve.
--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)