On Monday 12 of March 2012 01:49:35 Brian Harring wrote:
> On Sun, Mar 11, 2012 at 04:14:33PM +0100, Ch??-Thanh Christopher Nguy???n 
wrote:
> > Ciaran McCreesh schrieb:
> > >> Is there really much of a benefit to this?  I guess for anybody who
> > >> runs scripts to mass-manipulate ebuilds it might be helpful, but I
> > >> think all the package managers planned on supporting all the EAPIs for
> > >> quite a while longer.
> > > 
> > > We have to support them indefinitely. It's not possible to uninstall a
> > > package whose EAPI is unknown.
> > 
> > Would it be feasible to do a pkg_pretend() check and refuse
> > install/upgrade if packages with unsupported EAPI  are detected?
> 
> The question should be "is it worth doing it", rather than "can we
> hack out something".
> 
> As Ciaran said, PM's are going to be supporting EAPI1 indefinitely

In principle, it's actually entirely possible for any PM to start supporting 
exclusively completely API and ABI-breaking EAPI.

There's always the problem with self-upgrading software as it needs to somehow 
predict (and limit) its development to keep upgrade paths.
We have this exact problem where I work (with updating basestation SW) and 
some solution for this software is to stop being self-upgrading.

With external upgrade tool (which would rsync package tree do any 
vdb/metadata-magic needed) one could replace current PM with latest, API/ABI-
incompatible PM version.

Now, it may not really make sense for PM as upgrade process of PM itself isn't 
any different from upgrade process of any other package, still it would allow 
any API/ABI-breaking ebuild format changes to be introduced if we really need 
them so badly.

-- 
regards
MM