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

Reply via email to