1 |
Steven J. Long <slong@××××××××××××××××××.uk> wrote: |
2 |
> |
3 |
> From what you've written, the first thing that springs to mind is |
4 |
> /etc/portage/postsync.d/ which has q-reinitialize in it. I have that |
5 |
> activated, and run eix-sync after emerge --sync in update, which takes |
6 |
> care of overlays. |
7 |
> Which answers why postsync isn't sufficient in and of itself. |
8 |
|
9 |
I don't understand why postsync.d is not sufficient and why you run |
10 |
eix-sync *after* emerge --sync (it should be run *instead of*). |
11 |
eix-sync alone normally uses this order (only relevant tasks listed): |
12 |
|
13 |
1. layman ... |
14 |
2. emerge --sync [ hence, followed by postsync.d hooks ] |
15 |
3. @-hooks from /etc/eix-sync.conf |
16 |
4. eix-update |
17 |
5. eix-diff |
18 |
|
19 |
so if you use postsync.d to update a local overlay according to changes in |
20 |
the tree (or of a layman overlay) this update should be visible in eix. |
21 |
If you do not use eix, postsync.d should do as well... |
22 |
|
23 |
If you want to avoid postsync.d (though I still do not understand why) |
24 |
and use eix directly you can use the @-hooks: |
25 |
Put e.g. into /etc/eix-sync.conf the lines |
26 |
|
27 |
@StatusInfo Updating local overlay |
28 |
@/path/to/command_to_update_local_overlay |