| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 2009.06.07 10:34, Ulrich Mueller wrote: |
| 5 |
> >>>>> On Sun, 07 Jun 2009, Steven J Long wrote: |
| 6 |
> |
| 7 |
> > I'd just like to know what the implications would be for users if |
| 8 |
> we |
| 9 |
> > kept the .ebuild extension, and a new PMS were rolled out stating |
| 10 |
> > that the mangler were allowed to find the EAPI without sourcing |
| 11 |
> (and |
| 12 |
> > giving the restrictions) once portage 2.2 was stable, or the |
| 13 |
> ability |
| 14 |
> > to handle this backported to 2.1.6, and issued in a release? |
| 15 |
> |
| 16 |
> Even if we do only a one-time change of the file extension, can we |
| 17 |
> ever get rid of the old extension? Or are we then stuck with two |
| 18 |
> extensions in the tree until the end of time? |
| 19 |
> |
| 20 |
> Let's assume for the moment that we change from ".ebuild" to ".eb". |
| 21 |
> Then we obviously cannot change all ebuilds in the tree to ".eb", |
| 22 |
> otherwise old Portage versions would see an empty tree and there |
| 23 |
> would |
| 24 |
> be no upgrade path. |
| 25 |
> |
| 26 |
> Or am I missing something? |
| 27 |
> |
| 28 |
> Ulrich |
| 29 |
|
| 30 |
First, lets be clear that the upgrade path related problems are driven |
| 31 |
by the EAPI change, not the .ebuild to .eb change. That serves only to |
| 32 |
allow the new EAPI to be introduced immedately and hide the change from |
| 33 |
older package managers |
| 34 |
|
| 35 |
The upgrade path issue remains even if we do the usual Gentoo introduce |
| 36 |
new features to the package manager then wait a year or so before they |
| 37 |
are deployed. Without the .ebuild to .eb change. late upgraders will |
| 38 |
get the error messages in Appendix A of the GLEP when these features |
| 39 |
are relesed. |
| 40 |
|
| 41 |
To keep an upgrade path, package managers and their dependencies need |
| 42 |
to use EAPI 0, 1 or 2. (EAPI 3 is not yet out) How far back should the |
| 43 |
upgrade path extend? |
| 44 |
|
| 45 |
As you suggest, even with .ebuild to .eb change.its not a clean break |
| 46 |
with the past but would happen over time, with ebuilds for new package |
| 47 |
versions being migrated to the new format. For example we would |
| 48 |
have |
| 49 |
foo-2.1-r1.ebuild |
| 50 |
foo-3.0.eb |
| 51 |
portage-2.3.ebuild |
| 52 |
portage-3.0.eb |
| 53 |
|
| 54 |
Portage-2.3 will understand the later EAPI but will itself, use only |
| 55 |
EAPI, 0, 1 or 2. |
| 56 |
|
| 57 |
With the .ebuild to .eb change. users who do not upgrade portage will |
| 58 |
not see newer versions of foo. Without it, they will get the error |
| 59 |
messages in Appendix A of the GLEP. This will have the side effect of |
| 60 |
driving the adoption of the newer package managers. |
| 61 |
|
| 62 |
It is not suffcient to have portage-2.3.ebuild as understanding later |
| 63 |
EAPI files. All of its dependencies need to keep to EAPI 0, 1 or 2. |
| 64 |
These must be the last packages to migrate to later EAPIs. |
| 65 |
|
| 66 |
Thats just portage. The same reasoning applies to any other package |
| 67 |
manager and there are at least three. This begs the question of how |
| 68 |
friendly do we want to be to derivitive distros that use our tree but |
| 69 |
their own package manager? |
| 70 |
|
| 71 |
Upgrade path issues need to be addressed in the GLEP. I will add |
| 72 |
something like the above in the next version. |
| 73 |
|
| 74 |
- -- |
| 75 |
Regards, |
| 76 |
|
| 77 |
Roy Bamford |
| 78 |
(NeddySeagoon) a member of |
| 79 |
gentoo-ops |
| 80 |
forum-mods |
| 81 |
treecleaners |
| 82 |
trustees |
| 83 |
|
| 84 |
|
| 85 |
|
| 86 |
-----BEGIN PGP SIGNATURE----- |
| 87 |
Version: GnuPG v2.0.11 (GNU/Linux) |
| 88 |
|
| 89 |
iEYEARECAAYFAkoryrUACgkQTE4/y7nJvashtQCgkO+feHG2BBGLOTObrwq72iOx |
| 90 |
nI4AoNZ67Mhq4yEKYTzfBOPmu98Py9Mc |
| 91 |
=GB62 |
| 92 |
-----END PGP SIGNATURE----- |
Archives