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