GLEP 83: EAPI deprecation
|Author||Ulrich Müller <firstname.lastname@example.org>|
|Posting history||2022-07-11, 2022-07-31|
Introduce standardized criteria for deprecation and banning of EAPIs.
So far, old EAPIs were deprecated by the Gentoo Council in an ad-hoc manner. No fixed criteria were used, resulting in unpredictable deprecation times after approval of newer EAPIs. Standardized criteria for deprecation and banning will make the life cycle of EAPIs more predictable.
A deprecated EAPI is no longer required for the upgrade path of users' systems. Its use is discouraged, and tools like pkgcheck will warn about this .
A banned EAPI must no longer be used, neither for new ebuilds, nor for updating of existing ebuilds .
The Gentoo Council will deprecate an EAPI when
- two newer Council-approved EAPIs are supported by the stable version of Portage, and
- one of them has been supported for 24 months.
The Gentoo Council will ban a deprecated EAPI when
- 24 months have passed since its deprecation, and
- it is used by fewer than 5 % of ebuilds in the Gentoo repository.
EAPIs used in profiles are outside the scope of this GLEP.
Timing of EAPI deprecation is a trade-off between different factors. On the one hand, the total number of EAPIs in active use should be limited; this will prevent the learning curve for new developers and contributors from becoming too steep and will help to reduce code complexity, e.g. in eclasses.
On the other hand, an upgrade path to a stable system is guaranteed for one year, plus limited support for systems that are outdated more than a year . Therefore, previous EAPIs are still required during that time. A period of 24 months before deprecation has been chosen, which is more than the required minimum and will allow projects to support a longer upgrade path.
Requiring two newer EAPIs before deprecation will allow ebuilds that are otherwise seldom updated to be bumped to the next but one EAPI immediately.
A delay of 24 months between deprecation and ban will give ebuild authors enough time to update. This is especially relevant for overlays and downstream distributions. An additional requirement for banning an EAPI is that fewer than 5 % of ebuilds are using the EAPI in question. This requirement is defined to help keep the number of ebuild updates (and bug reports requesting them) manageable, as a banned EAPI is sufficient reason for updating an ebuild.
The following table compares the actual dates of deprecations and bans  with the dates that would have resulted from the criteria proposed in this GLEP ("new date").
|stable||usage < 5 %||actual date||new date||months||actual date||new date||months|
|[*]||Extrapolated date, obtained by fitting data between 2021-01-01 and 2022-07-31 with an exponential function.|
|||"EAPI deprecation", Gentoo Council meeting summary 2013-04-09 (https://projects.gentoo.org/council/meeting-logs/20130409-summary.txt). Note: The original quote says "Repoman" instead of "pkgcheck".|
|||"Ban on EAPI 1 and 2 should extend to updating EAPI in existing ebuilds", Gentoo Council meeting summary 2014-03-11 (https://projects.gentoo.org/council/meeting-logs/20140311-summary.txt)|
|||"Upgrade path for old systems", Gentoo Council meeting summary 2009-11-09 (https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt)|
|||Gentoo Package Manager Specification project (https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification#EAPI_life_cycle)|