Am Dienstag, 6. März 2018, 02:52:54 CET schrieb Matt Turner:
> EAPI 2 removal bug:
> It seems like tons of churn to update old stable ebuilds to a new
> EAPI, just for its own sake. Take 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.

OK so here's my personal opinion: 

Is it worth the effort? Yes, see below.
Is it a high priority task? No.

Is it really that much effort? Well, we're even in the case of EAPI=2 talking 
about only 400 ebuilds of 35000 in total. That's roughly 1% of the tree. And 
I'd strongly suspect that even without the EAPI update it would make very much 
sense to check these 400 old ebuilds and test whether they still work as 

What do we gain? 

* Mainly, less stuff to memorize. I'll be throwing a party on the day when the 
last EAPI=0 ebuild is gone. (In the retirement home, probably.)

* Also, it's not just having a bigger number, but also useful features...

Why now EAPI=2? 

* EAPI=3 is nearly gone (27 ebuilds left, scheme & java please get a move! :)
* EAPI=2 is the one with the next-least ebuilds.

While it would be very nice to remove EAPI=0, let's go for easier targets 
first; the number of EAPI=0 ebuilds will decrease organically in the meantime.

[Interestingly, as long as no specific efforts are made, the number of ebuilds 
in all deprecated EAPI decreases roughly equally and exponentially. That means
the probability of any old ebuild to be removed within a certain time interval 
is a constant as function of time...]

Andreas K. Hüttel
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to