1 |
Sergei Trofimovich posted on Sun, 15 Apr 2012 12:25:12 +0300 as excerpted: |
2 |
|
3 |
> On Sun, 15 Apr 2012 16:53:04 +0800 Patrick Lauer <patrick@g.o> |
4 |
> wrote: |
5 |
> |
6 |
>> On 04/15/12 16:16, Ryan Hill wrote: |
7 |
>> > Right now we have support in some packages for user patches - those |
8 |
>> > being patches dropped into /etc/portage/patches/pkgname/ - which are |
9 |
>> > automatically applied. Because this feature is implemented by |
10 |
>> > epatch_user() in eutils.eclass, it is only available for ebuilds that |
11 |
>> > inherit eutils and explicitly call epatch_user or inherit another |
12 |
>> > eclass that calls it in an exported phase (eg. base). The end result |
13 |
>> > is a very inconsistent experience, |
14 |
>> > where user patches may or may not work not only on a |
15 |
>> > package-by-package basis, but ebuild-by-ebuild. |
16 |
>> > |
17 |
>> > Is there any reason why this couldn't just be done in the package |
18 |
>> > manager, making user patches available for all ebuilds without code |
19 |
>> > changes? |
20 |
|
21 |
+100 |
22 |
|
23 |
>> From a debugging / bug wrangling perspective it's bad because there's |
24 |
>> no way for me to see if someone accidentally patched in something |
25 |
>> unexpected. (And we do have creative users :) ) |
26 |
|
27 |
The existing infrastructure already reports the application of user |
28 |
patches. I know, as I use it regularly, and rely on the ebuild output to |
29 |
double-check that it's being applied, when something goes wrong. |
30 |
|
31 |
>> It's a neat feature, but I'm moderately opposed to it unless we can get |
32 |
>> reporting in place so I can definitely see (e.g. from a logfile or |
33 |
>> error message) that there's been some ebuild modifications. |
34 |
|
35 |
Then you should be all for it, since that's already there so your only |
36 |
condition is to continue existing practice when epatch_user is applied |
37 |
globally. =:^) |
38 |
|
39 |
> For an advanced user it's already just a matter of adding |
40 |
> |
41 |
> post_src_prepare() { |
42 |
> epatch_user |
43 |
> } |
44 |
> |
45 |
> to '/etc/portage/bashrc' and screw thing up, right? |
46 |
|
47 |
That works for many ebuilds, but unfortunately not all, as base.eclass |
48 |
isn't inherited by all, meaning epatch_user isn't always recognized. =:^( |
49 |
|
50 |
I hacked it up to work a bit more reliably, here, but it's ugly (lots of |
51 |
sourcing complaints to /dev/null in ordered to get it from the eclass |
52 |
into the environment and avoid having to manually maintain it; jed are my |
53 |
initials, I often use them to avoid namespace collision and ease |
54 |
grepping): |
55 |
|
56 |
$>>cat /etc/portage/bashrc |
57 |
post_src_prepare () { |
58 |
. epatch_jed |
59 |
} |
60 |
|
61 |
$>>cat /usr/local/sbin/epatch_jed |
62 |
# user-patch helper, in case base.eclass isn't inherited |
63 |
type epatch_user >/dev/null 2>&1 && epatch_user || { |
64 |
bash -c " . $PORTDIR/eclass/eutils.eclass 2>&- ; epatch_user " |
65 |
} |
66 |
|
67 |
$>> |
68 |
|
69 |
I'm not absolutely sure that catches everything, and it's a nasty fragile |
70 |
hack (I had problems with bash-var read-only errors shorting out the |
71 |
process at one point), but it seems to be working for everything I've |
72 |
needed it for including ebuilds that don't inherit base.eclass, at this |
73 |
point. |
74 |
|
75 |
> eutils.eclass:epatch_user() could be more noisy (ewarn?) when applies |
76 |
> user patches. That way you could easier see something odd happening in |
77 |
> build.log. |
78 |
|
79 |
Your (I think) idea elsewhere, to cat the patches into the log, is |
80 |
interesting. But that could arguably be TOO noisy for big patches, say |
81 |
entire feature-adds. Maybe add yet another portage command-line option |
82 |
to (en|dis)able it? That way the current output could flag the |
83 |
possibility, and wranglers/maintainers could request the longer output if |
84 |
necessary. |
85 |
|
86 |
-- |
87 |
Duncan - List replies preferred. No HTML msgs. |
88 |
"Every nonfree program has a lord, a master -- |
89 |
and if you use the program, he is your master." Richard Stallman |