[gentoo-dev] Re: Re: Making user patches globally available

[Steven J Long]

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 ;-)