Re: [gentoo-dev] Eclass vs EAPI For Utility Functions (Patching/etc)

[Pacho Ramos <pacho@gentoo.org>]

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.