| 1 |
Ulrich Mueller wrote: |
| 2 |
> Let's assume for the moment that we change from ".ebuild" to ".eb". |
| 3 |
> Then we obviously cannot change all ebuilds in the tree to ".eb", |
| 4 |
> otherwise old Portage versions would see an empty tree and there would |
| 5 |
> be no upgrade path. |
| 6 |
> |
| 7 |
> Or am I missing something? |
| 8 |
> |
| 9 |
|
| 10 |
That is a good point. Although things would probably break more |
| 11 |
gracefully than having old portage versions attempting to parse new |
| 12 |
ebuilds (maybe, maybe not). |
| 13 |
|
| 14 |
That actually makes me wonder - if we didn't change the extension at all |
| 15 |
could we somehow poison the portage tree so that old versions of portage |
| 16 |
would abort before doing anything dumb with a meaningful error message? |
| 17 |
|
| 18 |
As far as an upgrade path goes - we could provide a one-time tarball |
| 19 |
that will update portage (and its essential dependencies) to a version |
| 20 |
that can get users out of this bind. If a user has a system THAT old |
| 21 |
then they might just want to extract a stage1 tarball (manually - |
| 22 |
without overwriting /etc without care) and go from there. |
| 23 |
|
| 24 |
I'm not sure that gentoo generally supports graceful upgrades from very |
| 25 |
ancient systems to modern ones without keeping up to date. Other |
| 26 |
distros can do it since they do ~annual releases and users could just |
| 27 |
apply those sequentially. For portage we don't keep around all the |
| 28 |
files needed to do a sequential upgrade like this - if a user were to |
| 29 |
try to upgrade to a 3-year-old version of some package most likely it |
| 30 |
wouldn't be mirrored and upstream might not have it either. |
| 31 |
|
| 32 |
We obviously need to give some thought to not breaking old versions of |
| 33 |
portage, but given that portage will be only one of many problems if a |
| 34 |
user doesn't do an emerge -u world for 5 years I'm not sure we need a |
| 35 |
bulletproof solution... |
Archives