On Fri, 2019-05-24 at 11:00 +0000, Corentin “Nado” Pazdera wrote:
> May 24, 2019 11:39 AM, "David Seifert" <s...@gentoo.org> wrote:
>
> > +case ${EAPI} in
> > + [4-7]) ;;
> > + *) die "EAPI=${EAPI:-0} is not supported" ;;
> > +esac
> > +
>
> Hi,
>
> I often wondered, why using a eapi-whitelisting logic instead of
> eapi-blacklisting?
> This kind of change forces to touch the eclass for the next eapi
> bump, while being a more defensive
> writing style, is it really needed?
>
> Best regards,
> Corentin “Nado” Pazdera
>
Tbh, there's upsides and downsides to both approaches. Whitelisting
means someone has to do some due diligence in checking that everything
actually works with a newer EAPI. For most well-written, forward-
looking eclasses, they will generally work for newer EAPIs. On the
other hand, just look at EAPI 7 and BDEPEND: This required a lot of
implicit DEPEND changes (cmake-utils, python-utils, autotools), and as
such it was probably for the better that these were EAPI whitelisted.
