1 |
I debated where to post this, but the topic is fairly dev-oriented and |
2 |
has big long-term impact so I landed here. This really isn't |
3 |
organizational in nature. |
4 |
|
5 |
During the council meeting there was a bit of a philosophical debate |
6 |
over the proper role of EAPI vs implementing functions in eclasses. I |
7 |
felt that it was important enough to at least get more community input |
8 |
before we continue voting on features like user patching/etc which |
9 |
tend to favor an EAPI-based approach. |
10 |
|
11 |
I'll try to fairly frame the arguments, though I personally lean in |
12 |
the EAPI direction and I'll leave it to somebody else to fix my straw |
13 |
man. |
14 |
|
15 |
|
16 |
The Eclass argument goes like this: |
17 |
Eclasses already work in every PM. Half of what we're debating is |
18 |
already in eutils. Why move this code into the PM, where it has to be |
19 |
re-implemented everywhere? If anything we should be moving more PM |
20 |
functionality out and into eclasses where we can have competing |
21 |
implementations and more flexibility. |
22 |
|
23 |
|
24 |
The EAPI argument goes like this: |
25 |
Sure, you can have 14 different implementations of epatch which lets |
26 |
each maintainer use the one that makes the most sense. However, who |
27 |
wants to edit an ebuild which uses a "bad" epatch implementation and |
28 |
re-learn how to add a patch? Adding patches is a common thing, so why |
29 |
not have a standard way to do it? We can still have eclasses for |
30 |
one-offs. And how can you ever do something like user patches when |
31 |
they will only work if the maintainer cares to support them? |
32 |
|
33 |
|
34 |
I view this as not being unlike dealing with programs that encourage |
35 |
the use of Turing-complete configuration files. Sure, they give you a |
36 |
lot more power, but that power comes at a cost. Sendmail config files |
37 |
are a running joke, and if you want to control the niceness or |
38 |
ioniceness of an OpenRC service then you're going to have to read the |
39 |
script and possibly patch it. |
40 |
|
41 |
When there is no value in everybody doing things differently, why not |
42 |
just do them the same way? |
43 |
|
44 |
Besides, I think user-patches are a GREAT feature to have, and one I |
45 |
use all the time (without even thinking about it if a package with a |
46 |
patch gets rebuilt). As I said in the meeting, if we were selling |
47 |
Gentoo to make money, it would be the sort of feature that you'd |
48 |
advertise. Why make it hard to use such a distinctive advantage of a |
49 |
source-based distro? |
50 |
|
51 |
Since this month is the last one for this Council term as an added |
52 |
bonus you stack the next Council with folks who agree with you on this |
53 |
one... :) |
54 |
|
55 |
Rich |