| 1 |
On 25/03/2011 09:01, Martin Gysel wrote: |
| 2 |
> Hi |
| 3 |
> |
| 4 |
> Am 24.03.2011 14:13, schrieb Ed W: |
| 5 |
>> I use a bit of a blend and recently I have started trying to use |
| 6 |
>> /etc/portage/patches/cat/pkg (badly documented) as a way to hook into |
| 7 |
>> ebuilds without having to patch every version, forever, and lightly |
| 8 |
>> tweak the install. |
| 9 |
> |
| 10 |
> what type of patches belongs there? are this patches to the ebuild |
| 11 |
> itself or patches which get applied in ${S} automatically (like |
| 12 |
> epatch_user). |
| 13 |
> So if you already have experience with it and you say it's badly |
| 14 |
> documented, can you share your experience? |
| 15 |
|
| 16 |
Well, you can only use /patches/ for certain well behaved ebuilds that |
| 17 |
run certain ebuild functions (forgotten the specifics, check the docs?). |
| 18 |
So this limits it's usefulness generally |
| 19 |
|
| 20 |
Additionally you can do something somewhat similar using pre_/post_ |
| 21 |
hooks in portage/env/... |
| 22 |
|
| 23 |
Both methods feel a bit clumsy to me, and I think they should mainly be |
| 24 |
used for patches/fixes which you expect to apply on a long term basis |
| 25 |
and don't expect to evolve particularly on a version to version basis. |
| 26 |
eg patches to default configs/scripts or patches to relatively stable |
| 27 |
chunks of code that upstream is unlikely to change |
| 28 |
|
| 29 |
I think for bug fixes or stuff which is expected to change imminently, |
| 30 |
or stuff which is specific to a code version then it's much neater to |
| 31 |
use a modified ebuild in some local portage tree |
| 32 |
|
| 33 |
The big negative on the /env/ and /patches/ method is that they aren't |
| 34 |
self documenting, unlike a local portage tree which is shown explicitly |
| 35 |
in the output of emerge. I think this is the big dictator which guides |
| 36 |
when it's appropriate to be used? |
| 37 |
|
| 38 |
|
| 39 |
I also use a file overlay tree as the final step of my build process. |
| 40 |
This leaves a big separation between the files and the packages they |
| 41 |
came from. Also if it's a small change from a default config then it's |
| 42 |
not self documenting (consider that upstream makes a large change - how |
| 43 |
to patch that change in our overlay). Hence I prefer to use patches |
| 44 |
where possible, keeps it closer to the package, and keeps it self |
| 45 |
documenting. The overlay is most useful therefore for large config |
| 46 |
deviations (usually specific to the final environment) |
| 47 |
|
| 48 |
|
| 49 |
Good luck |
| 50 |
|
| 51 |
Ed W |
Archives