On Tue, Sep 6, 2016 at 8:51 AM, Kristian Fiskerstrand <k...@gentoo.org> wrote:
>
> I believe you're overthinking it, if we make it a guideline to include a
> section of the eclass (as many already have) that does e.g (take this
> for example purposes) there is no EAPI/PMS change needed
> case "${EAPI:-0}" in
> 4|5|6)
> ;;
> *) die "EAPI=${EAPI} is not supported" ;;
>
I think the question becomes then what do we do about eclasses that
don't follow the guideline?
With a PMS change we can in the future enforce that the eclass
explicitly declare support by making it break by default if nothing is
done. With the approach above an eclass works with any EAPI by
default as far as PMS is concerned, and we rely on eclasses to
self-destruct when they're supposed to.
I think this can be controlled if we're disciplined about catching
this in new eclasses. We can do a one-time commit to all existing
eclasses to add this code somewhere if the maintainers do not add it.
That might involve either just having the eclasses abort on any EAPI
by default, on anything but the oldest supported EAPI, or just putting
in an acceptance of all existing EAPIs in which case we accept the
problem as far as the next PMS update but no further. Obviously the
ideal solution is for eclasses to be properly maintained.
In general though I'm all for the proposal, and I tend to think that
it is best for an eclass to either support an EAPI or not, and not do
this per-function. If that leads to refactoring so much the better.
I'm flexible on exactly how it gets implemented, but both eclass
maintainers and users should have a clear understanding of what
is/isn't supported.
--
Rich
