[gentoo-dev] Re: Re: GLEP 55 Version 2

[Steven J Long]

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 ;-)