Re: [gentoo-dev] RFC: Eclasses and EAPI

[Rich Freeman]

On Tue, Sep 6, 2016 at 9:02 PM, Erik Mackdanz <stasibear@g.o> wrote:
> Kristian Fiskerstrand <k_f@g.o> writes:
>> inherited eclasses. having a whitelist in place and die if eclass is not
>> updated to handle it solves it.
>>
>> Thoughts? comments? cookies? threats?
>
> Wouldn't a blacklist be more practical than a whitelist?
>
>   root# cat /usr/portage/profiles/eclass.eapi.mask
>
>   fooutils.eclass >=6
>
> The problem seems infrequent enough that a blacklist is sufficient, like
> all the *.mask files in /usr/portage/profiles.
>
> The whitelist places a large testing burden on eclass authors on each
> EAPI bump, where 99% of the time there won't be any issue to fix.

A few things:

1.  Your syntax assumes that EAPIs are ordered (I'll let the
mathematicians go on about set theory).  Nothing about PMS requires
this, the next one could be "2B," or "Fred," or "😁."  (Apologies on
the last one if it doesn't come through, as I have no idea how UTF-8
safe email actually is.)  I don't think it is likely, but I know
somebody else will point it out if I don't.
2.  I think that requiring eclasses to be reviewed before use on a new
EAPI is a feature, and not a bug.  It is a trivial update if it is
fine, and depending on the nature of the eclass it might be trivial to
determine if there will be a problem.  If it isn't trivial to
determine if there is a problem, it is probably even more important
that it be reviewed.
3.  The whole problem driving this is people using EAPIs with eclasses
without realizing they fail in subtle ways.  If they're unmaintained,
this is even more likely to happen, and all the more reason to expose
the problem.  It is better to expose problems during design than at
runtime.
4.  EAPIs seem to come out about every other year right now.  Is it
really THAT hard to keep up with them?  And eclasses which fall behind
should probably be candidates for treecleaning anyway.

-- 
Rich