1 |
On Tue, 6 Sep 2016 09:19:42 -0400 |
2 |
Rich Freeman <rich0@g.o> wrote: |
3 |
|
4 |
> On Tue, Sep 6, 2016 at 8:51 AM, Kristian Fiskerstrand <k_f@g.o> wrote: |
5 |
> > |
6 |
> > I believe you're overthinking it, if we make it a guideline to include a |
7 |
> > section of the eclass (as many already have) that does e.g (take this |
8 |
> > for example purposes) there is no EAPI/PMS change needed |
9 |
> > case "${EAPI:-0}" in |
10 |
> > 4|5|6) |
11 |
> > ;; |
12 |
> > *) die "EAPI=${EAPI} is not supported" ;; |
13 |
> > |
14 |
> |
15 |
> I think the question becomes then what do we do about eclasses that |
16 |
> don't follow the guideline? |
17 |
> |
18 |
> With a PMS change we can in the future enforce that the eclass |
19 |
> explicitly declare support by making it break by default if nothing is |
20 |
> done. With the approach above an eclass works with any EAPI by |
21 |
> default as far as PMS is concerned, and we rely on eclasses to |
22 |
> self-destruct when they're supposed to. |
23 |
|
24 |
PMS is there to solve the technical problem of compatibility between |
25 |
ebuilds and package managers, and you sound like you want to use it to |
26 |
solve a social problem. |
27 |
|
28 |
If we can agree on a policy adding a check like this, then enforcing it |
29 |
should be a minor problem. Of course, it can become a problem with |
30 |
the usual developers who know better and are going to refuse to comply |
31 |
but again, this is a social problem. |
32 |
|
33 |
Adding additional layer of complexity and enforcing the policy via PMS |
34 |
sounds like you want to enforce the policy one level higher, so that |
35 |
the developers would find it harder to reject it. Does that really |
36 |
sound like the way to solve the problem? |
37 |
|
38 |
-- |
39 |
Best regards, |
40 |
Michał Górny |
41 |
<http://dev.gentoo.org/~mgorny/> |