[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] [PATCH] savedconfig.eclass: Remove old EAPI ED/EROOT workarounds
From:       David Seifert <soap () gentoo ! org>
Date:       2019-05-25 16:09:04
Message-ID: 33bcc8e424f411aba7ef42e1476a5e4649781dd5.camel () gentoo ! org
[Download RAW message or body]

On Fri, 2019-05-24 at 11:00 +0000, Corentin "Nado" Pazdera wrote:
> May 24, 2019 11:39 AM, "David Seifert" <soap@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.


[prev in list] [next in list] [prev in thread] [next in thread]