| 1 |
On Sat, 18 Oct 2014 21:50:11 +0100, David W Noon wrote: |
| 2 |
|
| 3 |
> > You can use unpack or prepare. The difference is that the former |
| 4 |
> > runs immediately before the prepare function in the ebuild, the |
| 5 |
> > latter immediately after. Not only does it save manifesting the |
| 6 |
> > ebuild each time you modify it, it saves having the remember to |
| 7 |
> > modify it at all after an update. More importantly, your work is |
| 8 |
> > not destroyed on the next sync. |
| 9 |
> |
| 10 |
> One can also use /etc/portage/bashrc and enable epatch_user on all |
| 11 |
> ebuilds. But neither of these is what I want. |
| 12 |
|
| 13 |
I think globally enabling it in bashrc is a little too risky for me. I |
| 14 |
only use that file to register a die hook so I know when an ebuild fails. |
| 15 |
|
| 16 |
> I put the src_prepare() function into the specific ebuilds that I want |
| 17 |
> to install patches, and I avoid having it in ebuilds where I don't |
| 18 |
> want patches applied. |
| 19 |
|
| 20 |
Isn't that the point of /etc/portage/env? You can enable what you want |
| 21 |
when you want. Either for all versions of a package or only one. |
| 22 |
|
| 23 |
> I accept that this is not a normal user's use case, but I'm not really |
| 24 |
> a normal user. |
| 25 |
|
| 26 |
Normal is optional, do whatever works for you. I sometimes use |
| 27 |
portage/env and sometimes copy the ebuild to my local overlay for |
| 28 |
modification. Each case is different. |
| 29 |
|
| 30 |
|
| 31 |
-- |
| 32 |
Neil Bothwick |
| 33 |
|
| 34 |
A good pun is its own reword. |
Archives