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

[Roy Bamford <neddyseagoon@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?
> 
> Ulrich

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 

The upgrade path issue remains even if we do the usual Gentoo introduce 
new features to the package manager then wait a year or so before they 
are deployed. Without the .ebuild to .eb change. late upgraders will 
get the error messages in Appendix A of the GLEP when these features 
are relesed. 

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?

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

Portage-2.3 will understand the later EAPI but will itself, use only 
EAPI, 0, 1 or 2.
 
With the .ebuild to .eb change. users who do not upgrade portage will 
not see newer versions of foo. Without it, they will get the error 
messages in Appendix A of the GLEP. This will have the side effect of 
driving the adoption of the newer package managers.

It is not suffcient to have portage-2.3.ebuild as understanding later 
EAPI files. All of its dependencies need to keep to EAPI 0, 1 or 2. 
These must be the last packages to migrate to later EAPIs. 

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?

Upgrade path issues need to be addressed in the GLEP. I will add 
something like the above in the next version.

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoryrUACgkQTE4/y7nJvashtQCgkO+feHG2BBGLOTObrwq72iOx
nI4AoNZ67Mhq4yEKYTzfBOPmu98Py9Mc
=GB62
-----END PGP SIGNATURE-----