From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: [gentoo-dev] Eclass vs EAPI For Utility Functions (Patching/etc)
Date: Sun, 15 Jun 2014 07:00:15 -0400 [thread overview]
Message-ID: <CAGfcS_kix1enpz4uwj5tO-Qeeqrp=8tKWjdMiC1QuUR-g8R4Tg@mail.gmail.com> (raw)
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
next reply other threads:[~2014-06-15 11:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-15 11:00 Rich Freeman [this message]
2014-06-15 12:14 ` [gentoo-dev] Eclass vs EAPI For Utility Functions (Patching/etc) Ciaran McCreesh
2014-06-15 13:30 ` Michał Górny
2014-06-19 22:05 ` [gentoo-dev] " Steven J. Long
2014-06-19 22:22 ` Rich Freeman
2014-06-15 23:36 ` [gentoo-dev] Auto-patching ebuilds themselves Was: " Duncan
2014-06-16 9:54 ` [gentoo-dev] " Pacho Ramos
2014-06-19 17:03 ` William Hubbs
2014-06-19 17:53 ` Rich Freeman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGfcS_kix1enpz4uwj5tO-Qeeqrp=8tKWjdMiC1QuUR-g8R4Tg@mail.gmail.com' \
--to=rich0@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox