Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Eclass vs EAPI For Utility Functions (Patching/etc)
Date: Mon, 16 Jun 2014 09:54:26
Message-Id: 1402912454.2466.10.camel@belkin5
In Reply to: [gentoo-dev] Eclass vs EAPI For Utility Functions (Patching/etc) by Rich Freeman
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 >
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.
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.