1 |
Steven J. Long posted on Tue, 16 Jul 2013 03:01:50 +0100 as excerpted: |
2 |
|
3 |
> Duncan wrote: |
4 |
>> Martin Vaeth posted: |
5 |
>> > Does your framework manage the ebuilds in some overlay, or is it |
6 |
>> > actually running tranparently during emerge (probably with a patched |
7 |
>> > version of portage), allowing e.g. to change metadata without |
8 |
>> > maintaining the ebuild in a separate local overlay? |
9 |
>> > (I guess that it is the former, but your choice of the path |
10 |
>> > /etc/portage/... suggests the latter) |
11 |
> |
12 |
>> the framework I've setup is repo agnostic and would find the ebuilds in |
13 |
>> whatever repo, main tree or active overlay, they appear in. |
14 |
> |
15 |
>> I've occasionally been frustrated by this, but until this gentoo/kde |
16 |
>> semantic-desktop policy change, particularly with epatch_user |
17 |
>> eliminating the need for most of the ebuild edits I used to do, it was |
18 |
>> just easier to do the manual hacking any time I needed to change an |
19 |
>> actual ebuild. |
20 |
> |
21 |
> Hmm why was a local overlay inappropriate? I thought you could mask |
22 |
> packages from specific overlays (or am i wrong about that?) |
23 |
|
24 |
I believe I may have misunderstood Martin's original comment intent. The |
25 |
below might more accurately address the situation. (Assuming I'm not |
26 |
getting too sleepy to think straight...) |
27 |
|
28 |
I do have a local overlay, and use it for one-offs, where the upstream |
29 |
ebuild's likely to include the patch relatively quickly, or where it only |
30 |
applies to a specific version so an update is likely to invalidate the |
31 |
patch in any case. |
32 |
|
33 |
But in the kde case that wouldn't work as the patches will need to be |
34 |
reapplied long-term -- no upstream inclusion, as I didn't want to deal |
35 |
with manually overlaying/patching every single revision bump, etc. |
36 |
|
37 |
Actually, for kde I run the betas from the overlay, and (since sometime |
38 |
in 4.10) have been running (and generally rebuilding about twice a week) |
39 |
the live-branch ebuilds (4.10.49.9999, 4.11.49.9999) when upstream |
40 |
branches along with the first rc. Particularly the live-branch ebuilds |
41 |
(and even more the live-trunk -9999 ebuilds, but I've not gotten /that/ |
42 |
brave yet) get updated in-place to adapt to upstream code changes as well |
43 |
as gentoo system changes, and I wanted my hassle-free application of my |
44 |
no-semantic patches until they no longer applied, at which point I wanted |
45 |
to know about it so I could redo them. |
46 |
|
47 |
So applying the patches direct-in-repo made most sense for me, with |
48 |
updates overwriting my changes, and the patches then reapplied on top of |
49 |
the updates. |
50 |
|
51 |
But making that an option's probably a good idea, agreed. |
52 |
|
53 |
> Not that it matters, in that I'm glad you've gone down this path. I'd |
54 |
> just like to know. |
55 |
> |
56 |
> From what you've written, the first thing that springs to mind is |
57 |
> /etc/portage/postsync.d/ which has q-reinitialize in it. I have that |
58 |
> activated, and run eix-sync after emerge --sync in update, which takes |
59 |
> care of overlays. Which answers why postsync isn't sufficient in and of |
60 |
> itself. Hmm I guess that means that means qgrep et al aren't complete, |
61 |
> which I've never noticed as I don't use overlays. |
62 |
|
63 |
There's also the fact that my patches change dependencies -- that's what |
64 |
they're DESIGNED to do, after all, kill the semantic-desktop deps -- thus |
65 |
invalidating portage's metadata cache, so if emerge --regen isn't |
66 |
triggered afterward, every emerge invocation will take longer. |
67 |
|
68 |
What my sync script (local version) basically does: |
69 |
|
70 |
1) test-me: see if the tree partition is mounted and mount it if |
71 |
necessary. |
72 |
|
73 |
2) setup-parms: grab niceness and parallel jobs from my portage |
74 |
configuration, etc. |
75 |
|
76 |
3) emerge sync and layman sync (backgrounded in parallel, using wait). |
77 |
|
78 |
4) ebuild-patch (that's my ebuild patching function, the interesting bit). |
79 |
|
80 |
5) emerge $EJobs --regen |
81 |
|
82 |
Then after the portage cache is updated, in background/parallel: |
83 |
|
84 |
6) emerge --fetch (options) @world |
85 |
|
86 |
7) eupdatedb (for esearch, with portage niceness applied) |
87 |
|
88 |
8) q -qr (with portage niceness applied) |
89 |
|
90 |
9) Then (while 6-8 are still backgrounded), spit out a "syncs done, |
91 |
fetches and db updates continuing in background" message, after which it |
92 |
returns me to a prompt while the background jobs complete. |
93 |
|
94 |
|
95 |
Obviously that'll need generalized for non-local use. 1 and 2 could be |
96 |
generalized into presync.d (ordered), 6-9 into postsync.d (parallel), 3 |
97 |
into simply sync.d (parallel), and 4 and 5 into immediate-postsync.d (or |
98 |
some such, ordered). |
99 |
|
100 |
Then people could simply drop scriptlets into the appropriate *sync.d dir |
101 |
and let the general script handle it. Meanwhile, #4, the ebuild-patch |
102 |
step that's of interest here, would become just another scriptlet file in |
103 |
immediate-postsync.d. |
104 |
|
105 |
> Additionally, like Martin, I assumed you were doing this in a local |
106 |
> overlay, not on the tree itself, with resultant rsync wipeout. So if we |
107 |
> can sort that out, by writing the output to: |
108 |
> "${local_overlay:=/usr/local/portage}/${ebuild#"$PORTDIR"}" |
109 |
> I'd be a lot happier. It'll fit much better in the process of pushing to |
110 |
> an external overlay as well. |
111 |
|
112 |
An option makes sense... |
113 |
|
114 |
> The other thing I was going to mention is that update -s wraps the whole |
115 |
> process, to filter the rsync output so it's only one line (the |
116 |
> performance thing I mentioned in the other post: I never expected that |
117 |
> to work so well but my mentor does the awk so I just tried in bash, and |
118 |
> was amazed. :) So we could: |
119 |
> a) get the list of ebuilds that have actually been changed via rsync, or |
120 |
> b) check what eix is reporting after (if the user has eix.) |
121 |
|
122 |
I think the generalized *sync.d approach should still be wrappable. And |
123 |
anything the wrapper handles can simply be left out of the *sync.d dir |
124 |
it'd otherwise be located in. |
125 |
|
126 |
> That's the trouble with glue-scripting: you have to consider the |
127 |
> interaction of quite a few disparate commands, and various end-user |
128 |
> setups. |
129 |
> |
130 |
> It's also what makes it useful, and fun to work on. :-) |
131 |
|
132 |
Indeed. =:^) |
133 |
|
134 |
-- |
135 |
Duncan - List replies preferred. No HTML msgs. |
136 |
"Every nonfree program has a lord, a master -- |
137 |
and if you use the program, he is your master." Richard Stallman |