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

[Duncan]

Sergei Trofimovich posted on Sun, 15 Apr 2012 12:25:12 +0300 as excerpted:

> On Sun, 15 Apr 2012 16:53:04 +0800 Patrick Lauer <patrick@g.o>
> wrote:
>
>> On 04/15/12 16:16, Ryan Hill wrote:
>> > Right now we have support in some packages for user patches - those
>> > being patches dropped into /etc/portage/patches/pkgname/ - which are
>> > automatically applied.  Because this feature is implemented by
>> > epatch_user() in eutils.eclass, it is only available for ebuilds that
>> > inherit eutils and explicitly call epatch_user or inherit another
>> > eclass that calls it in an exported phase (eg. base).  The end result
>> > is a very inconsistent experience,
>> > where user patches may or may not work not only on a
>> > package-by-package basis, but ebuild-by-ebuild.
>> >
>> > Is there any reason why this couldn't just be done in the package
>> > manager, making user patches available for all ebuilds without code
>> > changes?

+100

>> From a debugging / bug wrangling perspective it's bad because there's
>> no way for me to see if someone accidentally patched in something
>> unexpected. (And we do have creative users :) )

The existing infrastructure already reports the application of user 
patches.  I know, as I use it regularly, and rely on the ebuild output to 
double-check that it's being applied, when something goes wrong.

>> It's a neat feature, but I'm moderately opposed to it unless we can get
>> reporting in place so I can definitely see (e.g. from a logfile or
>> error message) that there's been some ebuild modifications.

Then you should be all for it, since that's already there so your only 
condition is to continue existing practice when epatch_user is applied 
globally. =:^)

> For an advanced user it's already just a matter of adding
>
>     post_src_prepare() {
>         epatch_user
>     }
>
> to '/etc/portage/bashrc' and screw thing up, right?

That works for many ebuilds, but unfortunately not all, as base.eclass 
isn't inherited by all, meaning epatch_user isn't always recognized. =:^(

I hacked it up to work a bit more reliably, here, but it's ugly (lots of 
sourcing complaints to /dev/null in ordered to get it from the eclass 
into the environment and avoid having to manually maintain it; jed are my 
initials, I often use them to avoid namespace collision and ease 
grepping):

$>>cat /etc/portage/bashrc 
post_src_prepare () {
        . epatch_jed
}

$>>cat /usr/local/sbin/epatch_jed 
# user-patch helper, in case base.eclass isn't inherited
type epatch_user >/dev/null 2>&1 && epatch_user || {
        bash -c " . $PORTDIR/eclass/eutils.eclass 2>&- ; epatch_user "
}

$>>

I'm not absolutely sure that catches everything, and it's a nasty fragile 
hack (I had problems with bash-var read-only errors shorting out the 
process at one point), but it seems to be working for everything I've 
needed it for including ebuilds that don't inherit base.eclass, at this 
point.

> eutils.eclass:epatch_user() could be more noisy (ewarn?) when applies
> user patches. That way you could easier see something odd happening in
> build.log.

Your (I think) idea elsewhere, to cat the patches into the log, is 
interesting.  But that could arguably be TOO noisy for big patches, say 
entire feature-adds.  Maybe add yet another portage command-line option 
to (en|dis)able it?  That way the current output could flag the 
possibility, and wranglers/maintainers could request the longer output if 
necessary.

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