On 04/26/2012 03:08 PM, Duncan wrote:
Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted:
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.
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. Any eclasses that currently
call epatch_user can have a conditional like this:
if has $EAPI 0 1 2 3 4 ; then
epatch_user
else
apply_user_patches_here
fi
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.
I think it might be better to die if it's not called in src_prepare,
like Ciaran originally suggested. This ensures that people don't forget
to call it when they are supposed to.
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.
It's no worse than epatch_user currently is. It's the responsibility of
the person who overrides src_prepare to call eautoreconf or whatever
else when necessary, so the package manager will not have the burden.
--
Thanks,
Zac
