* Re: [gentoo-dev] Eclass vs EAPI For Utility Functions (Patching/etc)
@ 2014-06-16 9:54 99% ` Pacho Ramos
0 siblings, 0 replies; 1+ results
From: Pacho Ramos @ 2014-06-16 9:54 UTC (permalink / raw
To: gentoo-dev
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.
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2014-06-15 11:00 [gentoo-dev] Eclass vs EAPI For Utility Functions (Patching/etc) Rich Freeman
2014-06-16 9:54 99% ` Pacho Ramos
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox