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 <patr...@gentoo.org>
> 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
