W dniu pon, 05.03.2018 o godzinie 17∶52 -0800, użytkownik Matt Turner
> 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?

Removing any code from package managers is unlikely, so that is not
an argument.

Removing code from eclasses is actually beneficial. Please remember that
EAPI changes are not isolated to the PMS, and eclasses also use them to
kill deprecated features and make other breaking changes.

Both PMS and eclasses add new features in new EAPIs. Others have already
bought some examples. To examples others have already mentioned you
could add new econf options [1]. As a result, bumping EAPI frequently
*improves* the quality of the package and sometimes fixes bugs (reported
or unreported).

Most importantly, killing old EAPIs makes Gentoo easier for
contributors. You may think it's normal to expect Gentoo developers
to know 7 EAPIs and the differences between them. It might be normal for
people who are around long enough to see most of them.
But e.g. in proxy-maint we don't want to teach people about 7 EAPIs
if only 1 or 2 of them are really relevant to what they're doing.

Finally, old EAPIs are simply more prone to mistakes. When the majority
of 'current' Gentoo packages, i.e. the packages Gentoo developers
usually touch, use new EAPIs, it is *really easy* to miss that some old
package is using an ancient EAPI and start scratching your head why
something does not work.

Killing old EAPIs proactively -- like many other proactive efforts --
has the advantage of making the work of others easier. If I end up
having to fix a dozen old packages because of some reverse dependency,
I'd really find it preferable that someone already did the EAPI bump for
me and I wouldn't have to focus at the same time on fixing some issue,
bumping EAPI, fixing tests and doing all the other long-overdue
maintenance tasks.


Best regards,
Michał Górny

Reply via email to