| 1 |
On Fri, May 24, 2019 at 1:24 AM Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
> |
| 3 |
> >>>>> On Fri, 24 May 2019, Mike Gilbert wrote: |
| 4 |
> |
| 5 |
> > On Thu, May 23, 2019 at 7:16 PM David Seifert <soap@g.o> wrote: |
| 6 |
> >> Given that there are no ebuilds in the tree using this eclass and being |
| 7 |
> >> in EAPI 0, 1 or 2 ( |
| 8 |
> >> https://qa-reports.gentoo.org/output/eapi-per-eclass/savedconfig.eclass/ |
| 9 |
> >> ), wouldn't it make more sense to just whitelist EAPI >= 4 and clean up |
| 10 |
> >> this backwards compatibility cruft instead? |
| 11 |
> |
| 12 |
> > I'm fixing a bug with the least invasive change possible. I'm not |
| 13 |
> > trying to rework the eclass. |
| 14 |
> |
| 15 |
> AFAICS, that backwards compatibility code consists of two case |
| 16 |
> statements, and the chance that removing them would break anything is |
| 17 |
> close to zero. So I wouldn't call it a "rework". :) |
| 18 |
> |
| 19 |
> I'd rather remove than update that code for deprecated EAPIs. No ebuild |
| 20 |
> would ever use it, so your updated code would never be tested. |
| 21 |
|
| 22 |
Again, I'm fixing a bug. Removing EAPI 0-2 compatibility is |
| 23 |
unnecessary to fix the bug. |
Archives