1 |
Martin Vaeth posted on Thu, 11 Jul 2013 07:25:37 +0000 as excerpted: |
2 |
|
3 |
> Independently on the overlay, I think your framework is very |
4 |
> interesting: |
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 |
To be explicit, I'm using the official gentoo/kde overlay, which of |
13 |
course is the only place with kde 4.11 series (4.10.80+) ebuilds ATM, |
14 |
since 4.11 is still pre-release and we're dealing with the beta (4.10.80, |
15 |
4.10.90) and rc (4.10.95+) sources and ebuilds. But the framework I've |
16 |
setup is repo agnostic and would find the ebuilds in whatever repo, main |
17 |
tree or active overlay, they appear in. |
18 |
|
19 |
Some background... |
20 |
|
21 |
For some years now some ebuilds have made use of the epatch_user function |
22 |
from eutils.eclass or base.eclass. That function made use of a patches |
23 |
tree organized by category and package at /etc/portage/patches/, |
24 |
automatically applying any patches it found in the directory |
25 |
corresponding to the ebuild being run. Originally, calling epatch_user |
26 |
was optional -- the ebuild had to inherit the appropriate eclass and call |
27 |
the function. However, with eapi-5, it's now a mandatory part of any |
28 |
eapi-5 compliant ebuild. |
29 |
|
30 |
Actually, I believe that idea originated with a guy (I've forgotten his |
31 |
name and AFAIK he's no longer a gentooer, IIRC his domain expired some |
32 |
time ago and I deleted the bookmark I had to it) who had a patched |
33 |
portage with hooks at selected spots in the code, and various optional |
34 |
utilities using those hooks for all sorts of useful stuff. It seems |
35 |
enough gentoo devs found his stuff useful, that portage gradually |
36 |
integrated many of his hooks and tools, including this one. |
37 |
|
38 |
Meanwhile, long before eapi-5 came along, I got tired of having to figure |
39 |
out whether dropping a patch in the /etc/portage/patches tree was going |
40 |
to work for a particular ebuild or not, and hacked up something using |
41 |
/etc/portage/bashrc and a couple stub scripts, that ensured that I had |
42 |
epatch_user available as a function, and ran it using one of the hooks |
43 |
portage integrated for such extensions, the post_src_prepare function, as |
44 |
I defined it in /etc/portage/bashrc. So for some time now, I've been |
45 |
able to simply drop source patches in the appropriate /etc/portage/ |
46 |
patches/ subdir and have them automatically applied, regardless of |
47 |
whether the ebuild actually called epatch_user or not. |
48 |
|
49 |
As anyone who for example tests gcc versions before they're unmasked will |
50 |
know, a patch tree of this nature comes in really handy for applying |
51 |
various source patches without having to manually modify the ebuild. =:^) |
52 |
|
53 |
But, while that works great for source patches, at times one has to |
54 |
modify ebuilds too, and there isn't yet an offical similar framework for |
55 |
automatically applying ebuild patches. |
56 |
|
57 |
I've occasionally been frustrated by this, but until this gentoo/kde |
58 |
semantic-desktop policy change, particularly with epatch_user eliminating |
59 |
the need for most of the ebuild edits I used to do, it was just easier to |
60 |
do the manual hacking any time I needed to change an actual ebuild. |
61 |
|
62 |
But with the gentoo/kde semantic-desktop policy change, that too changed, |
63 |
as I was now doing ebuild patching longer term and on a rather wider |
64 |
scale. So I needed something like epatch_user, but for the ebuilds |
65 |
themselves instead of for the sources the ebuilds used. |
66 |
|
67 |
|
68 |
Meanwhile, some time ago I setup a script that among other things ran |
69 |
emerge sync and layman -S (in parallel), then ran emerge --regen (with |
70 |
multiple jobs) to rebuild the cache to take into account layman's |
71 |
overlays. Over time, this script expanded a bit to take on additional |
72 |
tasks, including checking to see if my portage and sources partition was |
73 |
mounted before running the sync and mounting it if not, updating the |
74 |
esearch and portage-utils databases, doing an emerge --update --deep |
75 |
--fetch @world, etc. The script is called esyn (esync without the |
76 |
terminating c), and I run it instead of esync to automatically take care |
77 |
of all the stuff I'd otherwise do one command at a time at the beginning |
78 |
of an update run. |
79 |
|
80 |
|
81 |
So when the need for an ebuild-patching variant of the epatch_user |
82 |
function came up with this gentoo/kde policy change and my subsequent |
83 |
generation of all these ebuild patches I needed applied, it was rather |
84 |
natural to simply add another function to my esyn script, that after |
85 |
the syncs looped thru a tree paralleling /etc/portage/patches (which I |
86 |
chose to call /etc/portage/patches.ebuild), and upon finding a patch in |
87 |
that tree, looped thru each of the repos listed in $PORTDIR and |
88 |
$PORTDIR_OVERLAY (as set in make.conf), matching category and package to |
89 |
see if there are any matching ebuilds in that repo to patch. |
90 |
|
91 |
If it finds a matching ebuild, like epatch_user, it first tries applying |
92 |
the patch in a dry-run. If the patch applies in the dry-run, then it |
93 |
applies it for real. If the patch doesn't apply in the dry-run, then it |
94 |
could be an ebuild for an old version (in this case, kde 4.10 ebuilds |
95 |
still have the semantic-desktop USE flag and don't need patched, neither |
96 |
will the patches apply), or it might be an ebuild that had the patch |
97 |
applied already (unlike with rsync, unless there's a conflict, git |
98 |
doesn't overwrite local changes, so the patch stays applied at layman -S |
99 |
and an attempted re-apply will fail; if there's a conflict, I can git |
100 |
reset --hard the overlay and redo the overlay sync to pull down the |
101 |
update, after which, given the conflict with the patch I had previously |
102 |
applied, I'll likely need to create an updated patch to apply), etc, so |
103 |
the function simply skips that ebuild and moves on to the next. |
104 |
|
105 |
At this point it's all rather hacked together, but it works here. I |
106 |
expect that over time, as the ebuilds from the gentoo/kde overlay and |
107 |
eventually in the main tree change, I'll find the patches don't apply and |
108 |
my updates break, at which point I'll update the patches and/or update |
109 |
the ebuild patching function as necessary. Based on past experience, on |
110 |
my own I'd get something semi-robust for my own setup in a few months to |
111 |
a year, tho it still wouldn't necessarily work well for others. Of |
112 |
course if I were to turn the whole thing into a publicly available |
113 |
project and take patches or even make it a publicly managed project (much |
114 |
like kde-sunset), I expect it'd mature much faster and would be become |
115 |
rather less hacky and rather more general purpose relatively quickly, |
116 |
such that with the help of others it'd likely be generally usable and |
117 |
reasonably stable within a couple months, instead of the year or so it'll |
118 |
likely take me on my own, after which it'll be rather more robust but |
119 |
still be targeted at only my system, if I don't take it public. |
120 |
|
121 |
-- |
122 |
Duncan - List replies preferred. No HTML msgs. |
123 |
"Every nonfree program has a lord, a master -- |
124 |
and if you use the program, he is your master." Richard Stallman |