Supporting Upgrades from “Old” Installs
Just had an interesting conversation with #gentoo-dev on supporting upgrades from old installs. There was also a very similar discussion on the gentoo-dev mailing list recently on Deprecating EAPI 0. Recently there have been a number of users on the forums upgrading from installs that only support EAPI 0. To achieve this currently, you have to manually intervene. There are various discussions on exact commands to run on the Gentoo Forums, so I won’t go into them again here.
For those that don’t know, EAPI is basically a specification of features available in the package manager. This allows Gentoo to support multiple package managers (Portage, Paludis, Pkgcore, etc) and still move the packaging format forward in a sensible manner.
It was initially suggested that a given set of packages (the trinary of Portage, Bash and Python seems to be the key, in my experience) and their required dependencies should be held back in terms of EAPI required to install.
At the end of the day, I think Gentoo needs to decide how old a system can get before an upgrade can no longer be officially supported. Currently I reckon you need to upgrade at least @system once a year to be able to upgrade without running into too many major issues. I also suspect that the maximum period that many users, particularly those in business environments, would like to have is longer than this (18 to 24 months).
As a method to determine how old a system can get before it is no longer sanely upgradeable, it was proposed that installs be set up, starting at about 1 year old (2008.0 could be used for this as it’s now almost a year old) and jumping back in set periods (perhaps 3 to 6 months). You then try to upgrade these installs to current stable, noting down the problems you encounter and how to resolve them.
Using the notes generated from the above tests, you can then, I think, set a benchmark for how old a system can be before it can no longer be sanely upgraded. In addition, it would be great if some (possibly (semi) official) documentation could be provided on the best manner to upgrade from each of the tested points (it may well be possible to generalise this documentation).
Once you have this information, you can then determine how old an EAPI needs to be supported and what intermediate versions of essential packages may need to provided. The exact method for then handling old systems can then be worked out. There are several possibilities, which include:
a) Hold back certain packages in terms of EAPI
b) Provide multiple revisions of certain packages at different EAPI levels (exactly how you’d version these was not discussed, but I suspect you could have EAPI 0 (or whatever the oldest “supported” EAPI is) as -r0 and EAPI 2 (or whatever the current EAPI is) as -r1.
Edit: I’ve also posted a poll on the forums to help gauge how long some users need the “supported upgrade” period to be.