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