On Mon, 5 Mar 2018 17:52:54 -0800 Matt Turner <[email protected]> wrote:
> EAPI 2 removal bug: https://bugs.gentoo.org/648050 > > It seems like tons of churn to update old stable ebuilds to a new > EAPI, just for its own sake. Take https://bugs.gentoo.org/648154 for > example. New ebuild added with EAPI 6 bumped from EAPI 2. Otherwise > functionally identical. Now asking arch teams to retest and > restabilize. Multiply by 100 or more. > > In the end we might get to delete some code from portage or an eclass? > Does this seem worth it? > New EAPI's don't just do nothing, some for example, add more power to users. EAPI6 is an especially significant example due to eapply_user becoming standardized. And with Perl packages at least, incrementing EAPI results in actual changes driven by the eclass: - Changes the names of various control variables - Makes perl tests on by default, and parallel by default ( previously required opt-in ) - Disables the legacy code path that kills the '.packlist' files, which are actually useful to some tools, and was the wrong place to kill those files in the first place. Incrementing EAPI also functions as an indicator that legacy approaches and interfaces are moved away from, which can also signify an improvement in ebuild quality. In short, while it looks superficially useless, I'd argue that there's a lot of nuanced benefits.
pgp4izKHabp6i.pgp
Description: OpenPGP digital signature
