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