1 |
On Sun, 17 May 2009 09:42:20 +0100 |
2 |
Neil Bothwick <neil@××××××××××.uk> wrote: |
3 |
|
4 |
> I think you can redefine ebuild functions |
5 |
> in /etc/portage/env/cat/pkg, so you could out a custom src_unpack() |
6 |
> in there. It should work if the ebuild has no src_unoack, so you |
7 |
> could do something like |
8 |
> |
9 |
> src_unpack() { |
10 |
> unpack ${A} |
11 |
> epatch mypatch |
12 |
> } |
13 |
> |
14 |
> I don't know how this would work with an existing src_unpack in the |
15 |
> ebuild, if you copied the existing function and added your patch. |
16 |
|
17 |
I use /etc/portage/bashrc for the same purpose. For instance, this is a |
18 |
patch I'm tacking onto portage ATM: |
19 |
|
20 |
if [[ ${CATEGORY}/${PN} == sys-apps/portage ]] |
21 |
then |
22 |
post_src_unpack() { |
23 |
cd "${S}"/bin |
24 |
epatch "/etc/portage/patches/misc-functions.patch" |
25 |
} |
26 |
fi |
27 |
|
28 |
As you can see, there are post_ and pre_ phases for all phase functions |
29 |
which can be used to do fancy stuff like this. |
30 |
|
31 |
I prefer /etc/portage/bashrc for this, since these hacks are usually |
32 |
only needed for a short time, so having them all in one place for an |
33 |
easy overview helps to keep the cruft down. |
34 |
|
35 |
/loki_val |