[gentoo-dev] Re: EAPI usage

[Duncan]

Ciaran McCreesh posted on Thu, 30 Aug 2012 21:11:02 +0100 as excerpted:

> On Thu, 30 Aug 2012 16:05:52 -0400 Michael Mol <mikemol@×××××.com>
> wrote:
>> Compile a list of existing ebuilds which depend on old EAPIs, and
>> you've got a TODO list. (eclasses, I don't know; I don't know if
>> eclasses explicitly express EAPI compatibility in metadata) Once that
>> list is cleared, yes, you can assume there are no ebuilds with a
>> specified EAPI of 0. I'd presume it would have been made widely known
>> that new ebuilds shouldn't use the old EAPI by that point, and so
>> support for the deprecated EAPI level can be abandoned.
>
> You can't uninstall a package if you don't support its EAPI.
>
> The "remove code" benefit applies to eclasses, not package manglers.

I've seen that reason given before, and it makes sense... to a point.

Would this work, tho?

In addition to the tree clean of EAPI-X to be dropped...

Some minimum time/versions (say six months) before a PM drops support for 
it, on PM upgrades it starts warning about the coming drop of EAPI-X 
support, giving the user a reasonable deadline (the same six months) to 
upgrade or uninstall said packages as PM versions after that date will be 
dropping support.

Then at a shorter deadline (say two months), start warning at each PM 
invocation.

When the upgrade that will drop support appears, if any packages of now 
unsupported EAPI-X remain installed, it simply dies with a warning that 
upgrading isn't possible as unsupported packages remain installed, 
instructing the user to upgrade or unmerge them first, before upgrading 
the PM.

By this time, the tree would have been clean of EAPI-X for the longer 
deadline (six months in this example), and the warning will have appeared 
on PM upgrade for the same period and on every PM invocation for the 
shorter period (two months here), so people doing anything close to 
regular upgrades will have long since upgraded past or unmerged whatever 
lagging packages they had merged.

For the people that do NOT upgrade frequently, the die before PM upgrade 
will force the issue, if/when they DO decide to upgrade.

Covering the case where the troublesome packages themselves have moved on 
beyond something the installed PM can handle, it's still possible to 
unmerge the package temporarily, then merge it again after they upgrade.

(If thought necessary, the usual I_KNOW_WHAT_IM_DOING override could be 
inserted, but in this case I think simply having them unmerge the 
packages in question is the safer alternative.  After all, it's only 
going to hit the folks who are SO far out of date that there's no 
bridging package version available, for the offending package.)

Of course there'd need to be special consideration given to critical 
toolchain and system boot packages, but /that's/ nothing new.

And as has always been the case, for the /extreme/ laggards, at some 
point, say two years out or whatever, simply don't support upgrading that 
far any more, with a clean install from stage-3 being the recommended 
alternative.

Of course an individual PM could choose to keep support for as long as 
they want, but unless I'm missing something, that'd let PMs drop support 
for old EAPIs if desired, with at least a reasonably sane upgrade path 
for both PM devs and users.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman