On 08/30/2012 08:33 PM, Duncan wrote: > Rich Freeman posted on Thu, 30 Aug 2012 20:38:11 -0400 as excerpted: > >> My main concern is doing bumps all the time just for their own sake. > > Yes. That's why I didn't tackle that side at all. But I've seen the > "PM's can never drop support for an EAPI once adopted" thing before, and > while there's quite a possibility I'm missing something as I'm no PM > expert, it does seem to me that rings hollow; that an EAPI drop COULD be > done, without too much disrupting either users or devs (PM or otherwise). > > But as the experts say otherwise, there probably /is/ something I'm > missing, which is why I asked.
It would be a bad idea to remove support for *uninstalling* an ebuild with a given EAPI, since any given system that the PM encounters could potentially have ebuilds with any old EAPI installed. OTOH, removing support for *installing* a given EAPI is quite feasible. In Portage, we occasionally deprecate EAPIs that only existed for the purpose of testing. Once an EAPI is deprecated, ebuilds using that EAPI can no longer be installed, but they can still be uninstalled (including execution of pkg_prerm/pkg_postrm phases). That said, deprecation of official EAPIs such as EAPI 0, 1, and 2 would not lead to much code being removed, because the later EAPIs share so much code with them. So, deprecating official EAPIs provides little or no benefit in terms of code maintenance. -- Thanks, Zac