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 <[email protected]> > 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
