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
signature.asc
Description: This is a digitally signed message part.
