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