On Tue, 6 Sep 2016 09:19:42 -0400 Rich Freeman <ri...@gentoo.org> wrote:
> 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.
PMS is there to solve the technical problem of compatibility between
ebuilds and package managers, and you sound like you want to use it to
solve a social problem.
If we can agree on a policy adding a check like this, then enforcing it
should be a minor problem. Of course, it can become a problem with
the usual developers who know better and are going to refuse to comply
but again, this is a social problem.
Adding additional layer of complexity and enforcing the policy via PMS
sounds like you want to enforce the policy one level higher, so that
the developers would find it harder to reject it. Does that really
sound like the way to solve the problem?
--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>
pgpiFCCwDk2_v.pgp
Description: OpenPGP digital signature
