Re: [gentoo-dev] RFC: Deprecating EAPI0

[Robert R. Russell]

On Saturday 21 March 2009 19:03:45 AllenJB wrote:
> Patrick Lauer wrote:
> > Hi all,
> >
> > with the discussion about EAPI3 we have now 4 (or 7, depending on how you
> > count them ;) ) EAPIs available or almost available. This is getting
> > quite confusing.
> > To make our lives easier I would suggest deprecating EAPI0 and migrating
> > existing ebuilds over some time to EAPI1 or higher until EAPI0 can be
> > obsoleted at some point in the future.
> > I would set the start of deprecation warnings about 3 months from now and
> > the obsoletion quite a time later, maybe 12 months from now, when a
> > sufficient amount of ebuilds has been migrated.
> >
> > Deprecating EAPI1 at the same time would reduce the amount of EAPIs we
> > have to think about, but since it has some changes like adding
> > src_prepare migration would not be as trivial. So I'd prefer keeping it
> > around a bit longer.
> >
> > Comments?
> >
> >
> > Patrick
>
> While there definitely arguments for deprecating EAPIs, I would suggest
> caution.
>
> A low number of active EAPIs can make life easier for developers, but it
> can also make life harder for some users. There are still users coming
> to the forums upgrading systems which only understand EAPI 0. I accept
> that Gentoo is certainly a relatively fast moving distro, but I think
> that developers also do need to consider users who have systems that are
> currently "just working" and may not upgrade often (once a year or even
> less)
>
> As such, I would suggest that forcing a move to the most recent stable
> EAPI is possibly unwise.
>
<snip>
> AllenJB

Note, this just my opinion. It may not be entirely practical or cover all the 
issues regarding backwards compatibility. I intend it to provoke questions 
and thought as to what a reasonable policy for backwards compatibility might 
cover.

Waiting a year or longer to upgrade a gentoo system carries a good risk of 
having something explode into a near unrecoverable mess.

I definitely do think that some major focus needs to be placed on how far 
behind a gentoo system could be and should still be expected to catch up.

An oversimplified example. Assume that I can find all required patches and 
source code to do the initial builds, and that all normal configuration file 
checks/updates are done after the current tree is installed.

I create three different virtual machines from cvs snapshots of the portage 
tree. The first is dated 6 months ago. The second is dated 12 months ago. The 
third is dated 18 months ago.

Which of these should be reasonably updateable to the current portage tree?

My suggestion is that policy should allow machine 1 to be updated through 
regular update procedures to the current tree, unless major changes dictate 
otherwise. Major changes being incompatible ebuild formats, toolchains, and 
other here is the line sorry kind of changes.

A careful operator should probably be able get machine 2 updated to the 
current tree, again unless major changes dictate otherwise. We should not 
make go out of our way to make upgrading from this point out hard for the 
operator, but, new growth should be favored over the ease of upgrading.

Machine 3 is just out of luck. Here is the new install cd and handbook, have 
fun.

Regular update procedures would be:
emerge --sync; emerge -uND world -f; emerge -uND world; revdep-rebuild; 
emerge --depclean;

The careful operator might update the toolchain first and emerge -e world or 
something similar.