1 |
Duncan wrote: |
2 |
> Martin Vaeth posted: |
3 |
> > Does your framework manage the ebuilds in some overlay, or is it |
4 |
> > actually running tranparently during emerge (probably with a patched |
5 |
> > version of portage), allowing e.g. to change metadata without |
6 |
> > maintaining the ebuild in a separate local overlay? |
7 |
> > (I guess that it is the former, but your choice of the path |
8 |
> > /etc/portage/... suggests the latter) |
9 |
|
10 |
> the framework I've setup is repo agnostic and would find the ebuilds in |
11 |
> whatever repo, main tree or active overlay, they appear in. |
12 |
|
13 |
> I've occasionally been frustrated by this, but until this gentoo/kde |
14 |
> semantic-desktop policy change, particularly with epatch_user eliminating |
15 |
> the need for most of the ebuild edits I used to do, it was just easier to |
16 |
> do the manual hacking any time I needed to change an actual ebuild. |
17 |
|
18 |
Hmm why was a local overlay inappropriate? I thought you could mask packages |
19 |
from specific overlays (or am i wrong about that?) |
20 |
|
21 |
Not that it matters, in that I'm glad you've gone down this path. I'd just |
22 |
like to know. |
23 |
|
24 |
From what you've written, the first thing that springs to mind is |
25 |
/etc/portage/postsync.d/ which has q-reinitialize in it. I have that activated, |
26 |
and run eix-sync after emerge --sync in update, which takes care of overlays. |
27 |
Which answers why postsync isn't sufficient in and of itself. Hmm I guess that |
28 |
means that means qgrep et al aren't complete, which I've never noticed as I don't |
29 |
use overlays. |
30 |
|
31 |
Additionally, like Martin, I assumed you were doing this in a local overlay, not |
32 |
on the tree itself, with resultant rsync wipeout. So if we can sort that out, by |
33 |
writing the output to: |
34 |
"${local_overlay:=/usr/local/portage}/${ebuild#"$PORTDIR"}" |
35 |
I'd be a lot happier. It'll fit much better in the process of pushing to an |
36 |
external overlay as well. |
37 |
|
38 |
The other thing I was going to mention is that update -s wraps the whole process, |
39 |
to filter the rsync output so it's only one line (the performance thing I mentioned |
40 |
in the other post: I never expected that to work so well but my mentor does the awk |
41 |
so I just tried in bash, and was amazed. :) So we could: |
42 |
a) get the list of ebuilds that have actually been changed via rsync, or |
43 |
b) check what eix is reporting after (if the user has eix.) |
44 |
|
45 |
However a postsync action similar to q would be the best; it just has to run after |
46 |
the overlays have been sync'ed. As I said I don't use overlays, so it's up to you |
47 |
and people like Martin to work the details of 'what and when' out. I'll help with |
48 |
the 'how'. I'd just prefer something that doesn't require a wrapper, but works with |
49 |
any emerge setup. |
50 |
|
51 |
Alternatively, if we can get eix to do it directly, it'd rock afaic. Though a |
52 |
developer I know refuses to use it, as he says it takes too long if you've got |
53 |
a cvs tree, or sth. Unfortunately, like you, mv doesn't do IRC, so I've not been |
54 |
able to get the two together for a chat to see if anything could be sorted, or |
55 |
whether it's intractable. |
56 |
|
57 |
Personally, I'm fine with a dep on eix fwiw. |
58 |
|
59 |
I'm reasonably sure you can hook whatever you like into eix-sync, as I recall |
60 |
telling people to just use it quite a lot back in the day (we do have postSync |
61 |
actions as well, one for -q quiet usage, if defined) but mv can tell us more, if |
62 |
eix can help. It seems the right spot, since eix-sync can run after emerge --sync |
63 |
and do all the overlays, so people are used to running it. iirc again you can use |
64 |
a postsync.d action, so it would be ideal. |
65 |
|
66 |
We just don't with update as we want the rsync filtering, and have to work when |
67 |
the user doesn't have eix, so it's always been separate. Having said that, if the |
68 |
user has eix running in postsync, that'll work too. |
69 |
|
70 |
That's the trouble with glue-scripting: you have to consider the interaction of |
71 |
quite a few disparate commands, and various end-user setups. |
72 |
|
73 |
It's also what makes it useful, and fun to work on. :-) |
74 |
|
75 |
-- |
76 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |