Ulrich Mueller wrote:
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?
That is a good point. Although things would probably break more
gracefully than having old portage versions attempting to parse new
ebuilds (maybe, maybe not).
That actually makes me wonder - if we didn't change the extension at all
could we somehow poison the portage tree so that old versions of portage
would abort before doing anything dumb with a meaningful error message?
As far as an upgrade path goes - we could provide a one-time tarball
that will update portage (and its essential dependencies) to a version
that can get users out of this bind. If a user has a system THAT old
then they might just want to extract a stage1 tarball (manually -
without overwriting /etc without care) and go from there.
I'm not sure that gentoo generally supports graceful upgrades from very
ancient systems to modern ones without keeping up to date. Other
distros can do it since they do ~annual releases and users could just
apply those sequentially. For portage we don't keep around all the
files needed to do a sequential upgrade like this - if a user were to
try to upgrade to a 3-year-old version of some package most likely it
wouldn't be mirrored and upstream might not have it either.
We obviously need to give some thought to not breaking old versions of
portage, but given that portage will be only one of many problems if a
user doesn't do an emerge -u world for 5 years I'm not sure we need a
bulletproof solution...
