Zac Medico wrote:
> Steven J Long wrote:
>> It seems there's two major cases, with autotools or without. In either
>> case, epatch_user should be called after Gentoo patches have been
>> applied.
>>
>> Why not make epatch_user set a variable to indicate that patches have
>> been applied, and only apply the patches on the first call?
>>
>> Then eautoreconf could call it before calling autoconf (and the ebuild
>> wouldn't need to worry about it.) And any custom src_prepare function
>> could call it when needed, if it needed to be done during the phase, and
>> not after.
>>
>> After src_prepare, the PM could just call it unconditionally, since it
>> will not apply the patches again, if it's already been called by the
>> ebuild.
>>
>> Does that make sense?
>
> Yeah, sounds roughly equivalent to Ciaran's suggested
> "apply_user_patches_here" approach [1], except that Ciaran suggested to
> make it an error if src_prepare doesn't call apply_user_patches_here (so
> people don't forget to call it when they should).
>
> [1]
> http://archives.gentoo.org/gentoo-
dev/msg_c228be85e0c4e577ad194e6004d59062.xml
Yeah, I saw that, but given that this would be standardisation around an
EAPI bump, I don't see the point in changing the name of the function to
mean exactly the same thing, only to make it much more inconvenient in
usage.
I feel there needs to be more thinking about what you mentioned, ie around
the lines of "user-patches are applied on top of Gentoo-patched sources."
This makes much more sense in process terms, since user-patches are more
likely to be included in Gentoo-patches, and thus easier to handle for
submission upstream. The alternative (user-patches applied to vanilla
sources) has much more likelihood for bad interaction with Gentoo patches or
changes.
If we stipulate that src_prepare transforms upstream sources into Gentoo-
official sources, then it only makes sense to epatch_user thereafter, and
there's no point burdening the ebuild, or its developer, with that task.
It also makes ebuilds much cleaner to read.
Where you have a build-system that requires epatch_user part way through
src_prepare, it's up to the ebuild, or more likely eclass for that build-
system, to call it at the appropriate time. (autoconf ebuilds clearly should
just inherit whatever eclass the team tells them to, and stop messing
around.)
In any event, specifying that the PM only calls epatch_user after
src_prepare if there are user-patches, and it hasn't been called already
(this is easiest done within epatch_user, ofc) allows ebuild or eclass
developers to override the default easily, while still keeping things easy
for most ebuilds.
eg: so far I've heard that: epatch_user && eautoreconf
..is desired behaviour, so I guess you want logic like:
if ((${#USER_PATCHES[*]})); then
((applied_user_patches)) || {
<.. apply the patches || die ..>
applied_user_patches=1
}
return 0
else return 1
fi
Given something like the above, the addition of a simple[1]: epatch_user
..to eautoreconf before the call to autoreconf, and after src_prepare in
ebuild.sh, cannot do any harm, and ensures that sources are patched without
adding any cruft to ebuilds.
I also think there would be merit in optionally including any user-patches
with binpkgs. This would be useful for transparency, ie debugging and
licensing concerns with respect to modified sources.
Regards,
Steve.
PS As you know, ofc, patches against vanilla sources can be done in a
pre_src_prepare bashrc hook, if one really has to for custom builds. I don't
think anyone's talking about implementing them; or should they be on the
table too?
[1] Yes, EAPI-dependent, so might need eg:
case $EAPI in 5|6) epatch_user;; esac
..depending on what else is happening, but simple in the sense that we don't
care about its return value in these contexts.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
