1i5t5.duncan at cox
Apr 26, 2012, 3:08 PM
Post #37 of 60
(169 views)
Permalink
|
|
Re: Making user patches globally available
[In reply to]
|
|
Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted:
> On 04/26/2012 02:55 AM, Duncan wrote:
>> Zac Medico posted on Wed, 25 Apr 2012 23:26:24 -0700 as excerpted:
>>
>>> On 04/25/2012 11:18 PM, Duncan wrote:
>>>> IOW, let's quit letting the perfect be the enemy of the good
>>> If that means settling on something that's fragile and prone to lots
>>> of bug reports, then it's not really practical
>> IMO[,] If all it does is the patching, but it /always/ does the
>> patching[,] and people know they need to use the overlay-ebuild
>> method to do anything beyond patching, [including eautoreconf,]
>> then it should "just work".
> Ignoring the problem doesn't make it go away. If we ignore the problem,
> then we end up dealing with bug reports of the form "FEATURES=userpatch
> doesn't work with this particular patch set" until the end of time.
Standard boilerplate resolved/DUP, pointing to the first one, resolved
like this:
NOTABUG/INVALID. The feature does what it says on the label and is
working as designed. The files are patched and the build bails out if
the patch fails. The userpatch feature is deliberately limited to
patching, thus keeping the problem manageable and the code transparent
and maintainable. For anything fancy, including patches that need
eautoreconf called afterward, the userpatch feature isn't the right
tool. Copy the ebuild to an overlay and edit it as necessary to both
apply the patch and eautoreconf or whatever else needs done afterward.
> Also, don't forget to consider the possibility of interference between
> FEATURES=userpatch and epatch_user (applying same patches twice).
The existing phaselock-file solution should continue to work there. Test
for the existence of a file and punt if it's found; touch the file on
first invocation.
The only caveat is that the existing eclass solution has changed the
filename before. Once the corresponding feature exists, both the eclass
and the feature will have to use the same filename so as not to conflict
with each other, thereby effectively locking down the name and preventing
further changes to it.
> Overall, the "apply_user_patches_here" approach [1] seems pretty
> reasonable to me.
>
> [1]
> http://archives.gentoo.org/gentoo-dev/
msg_c228be85e0c4e577ad194e6004d59062.xml
With the requirements that if the ebuild never calls it, it's still run
immediately after source_prepare, thus ensuring that it gets called, AND
that calling either autoreconf or eautoreconf without calling apply-user-
patches first is a repoman-checked error, it looks like it should work,
agreed.
But I'm a bit wary as to the robustness. And without a mechanism to
apply the patches at a particular point (arguably, post-src-prepare) even
in the absence of a specific apply-user-patches-here call, we're back
where we were without a global solution, but if the hard-invocation is
done, then we're back to either inefficiently running eautoreconf twice
or forced into doing likely failure-prone detection, thus the worry over
robustness.
But of course he who codes, decides. We have existing and already proven
code for the simple case, but if someone actually codes that complex
approach, and it actually does both get us global coverage and avoid
duplicated autoreconf runs, without hard to track down failures, I for
one will certainly bless them! =:^)
I just don't want to have to wait until kingdom come for the "perfect"
solution, when we already have a demonstrated "good enough 80-90% of the
time" solution ready to roll out globally, if we'd just do it.
It's also worth pointing out that nothing prevents rolling out the "good
enough" solution right away, then growing the complexity to cover the
harder autoreconf cases when a solution for them actually gets coded.
--
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
|
signature.asc
