[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev] Re: Making user patches globally available
From:       Duncan <1i5t5.duncan () cox ! net>
Date:       2012-04-28 2:29:09
Message-ID: pan.2012.04.28.02.29.09 () cox ! net
[Download RAW message or body]

Nikos Chantziaras posted on Fri, 27 Apr 2012 18:55:12 +0300 as excerpted:

> On 27/04/12 17:15, Duncan wrote:
>> Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted:
>>> Having the package manager interact with an eclass function like
>>> epatch_user is ugly, and it's unnecessary since we can pull all of the
>>> pieces into the package manager in EAPI 5.
>>
>> But that doesn't solve the problem of making it globally available,
>> since it only applies to packages/eclasses that already call
>> epatch_user for EAPIs thru current EAPI-4.
>>
>> In ordered to make it globally available, it cannot simply be an EAPI-5
>> thing, it must apply to all current ebuilds whether they (or an
>> inherited eclass) call epatch_user or not.  Which means that conflict
>> with the existing epatch_user is unavoidable, since it will either try
>> to run twice where it's already called, or it won't run at all where
>> it's not.
> 
> According to the source, calling it twice is perfectly safe.

That's actually one of the points I've been making, that if we simply 
force an epatch_user at approximately post_src_prepare, the existing code 
already deals with multiple calls just fine.

The problem appears if we then decide that we're going to do something 
with eautoreconf immediately thereafter.  

* if we just call it, we're potentially doing extra work both when the 
patch didn't require it, and when the ebuild already invoked eautoreconf 
after doing its own patching.

* elif we try to somehow detect that it needs to be run, that's a huge 
amount of additional complexity we're now talking about adding to what 
WAS a simple globalization of already tested working code.

* elif we try to force developers to call it at some point via repoman 
check or the like, thus letting them decide, then we're possibly looking 
at eapi5, and in any case, we just lost the point of the entire exercise, 
to make it global without forcing a touch of every existing ebuild in the 
tree that doesn't do it yet.

Rock, hard place, with us between them!

That's why I proposed up-thread that at least for now we go with the 
simple option, simply have the PM call epatch_user (either supplying its 
own internal function or sourcing the eclass to get the existing eclass 
version), and just punt on the eautoreconf stuff for now.  As I said 
there, based on my experience anyway, that covers the for me at least 
80-90% of use-cases where the patch isn't complex enough to require an 
eautoreconf, using code that's already known to be solid and well 
tested.  For the remaining 10-20%, the old solution, copying the ebuild 
to an overlay and adding the patch calls and any other necessary 
modifications manually, still works.

I'd rather take the "good solution", the well tested code we have now, 
and apply it globally, yielding the 80-90% reduction in forced personal 
overlay ebuilds as a result, and continue to deal with the 10-20% than 
need eautoreconf or other processing manually, now, instead of waiting 
possibly forever for a "perfect" solution that might or might not ever 
come, even if in theory it could raise that 80-90% to 99%+.

But Zac and a few others believe that what I called the "good" solution 
will result in a more or less continuous flood of bugs from people who 
expect epatch_user (or whatever replaces it) to "just work" for that 
perhaps 10-20% where eautoreconf is required as well, and don't believe 
it's an acceptable tradeoff.  Since they're the devs dealing with the 
bugs, not me, that's a trump card I can't counter.  They win.  
Unfortunately that means we're stuck waiting for a "perfect" solution 
that may never come, once again, or at least with an eapi5 solution that 
even when adopted won't reach global coverage for many many years to 
come.  Oh, well...

Unless you're talking about eautoreconf, not epatch_user.  Actually, 
calling eautoreconf extra times should be safe.  It'll just take longer, 
potentially MUCH longer, relative to the current merge time of some 
affected packages.

(There's the question too, of what happens if eautoreconf is called on a 
non-autotools package.  But at a suitably high level, that simply gets 
lumped in with the general robustness question on the whole approach.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


[prev in list] [next in list] [prev in thread] [next in thread]