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