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