1 |
Duncan <1i5t5.duncan@×××.net> wrote: |
2 |
> |
3 |
> I do have a local overlay, and use it for one-offs |
4 |
|
5 |
You can have several local overlays, one particularly dedicated for KDE |
6 |
(and if you put the directory of the latter under git control, |
7 |
you could also easily make it public e.g. on GitHub so that other users |
8 |
can use it without using your framework). |
9 |
|
10 |
> But in the kde case that wouldn't work as the patches will need to be |
11 |
> reapplied long-term -- no upstream inclusion, as I didn't want to deal |
12 |
> with manually overlaying/patching every single revision bump, etc. |
13 |
> [...] So applying the patches direct-in-repo made most sense for me |
14 |
|
15 |
Why not use the script to patch the ebuilds after fetching |
16 |
but store the patched ebuilds in your dedicated overlay instead |
17 |
of the original location? |
18 |
If you give this dedicated overlay a higher priority in |
19 |
/etc/portage/repos.conf, portage will install the patched |
20 |
ebuilds if they are available. |
21 |
|
22 |
For a general framework, one could e.g. support directories |
23 |
of the form |
24 |
|
25 |
/etc/portage/ebuild.patches/FROM:TO/whatever |
26 |
|
27 |
so that "whatever" (patches, sed-commands, etc; depends how |
28 |
your framework works) is applied by your framework after |
29 |
it copied the corresponding ebuild from repository FROM to TO. |
30 |
In particular, currently you would use only something like |
31 |
|
32 |
/etc/portage/ebuild.patches/kde-experimental:kde_unsemantic/... |
33 |
|
34 |
The scripts in your framework can use functions like |
35 |
portageq get_repo_path / FROM |
36 |
or the quicker new |
37 |
eix-header -p FROM |
38 |
to find out the corresponding paths, once these repositories |
39 |
are set up (and in the eix database, respectively). |
40 |
|
41 |
> There's also the fact that my patches change dependencies -- that's what |
42 |
> they're DESIGNED to do, after all, kill the semantic-desktop deps -- thus |
43 |
> invalidating portage's metadata cache, so if emerge --regen isn't |
44 |
> triggered afterward, every emerge invocation will take longer. |
45 |
|
46 |
For a local overlay you do not need to run emerge --regen. Running |
47 |
|
48 |
egencache --repo=kde_unsemantic --update --update-use-local-desc |
49 |
|
50 |
after applying the patches is sufficient: If kde_unsemantic has |
51 |
a higher priority in /etc/portage/repos.conf, its metadata will |
52 |
be taken. |
53 |
BTW, I would suggest to put into metadata/layout.conf of |
54 |
kde_unsemantic the lines |
55 |
|
56 |
cache-formats = md5-dict |
57 |
thin-manifests = true |
58 |
|
59 |
and if you use git also into .gitignore the line |
60 |
|
61 |
/metadata/md5-cache/ |
62 |
|
63 |
so that users have to run the above egencache command on their own |
64 |
(which is better than having possibly outdated checksums for |
65 |
eclasses in which case md5-cache would not help them, anyway). |
66 |
|
67 |
>> That's the trouble with glue-scripting: you have to consider the |
68 |
>> interaction of quite a few disparate commands, and various end-user |
69 |
>> setups. |
70 |
|
71 |
That's why for end-users publishing the patched overlay would |
72 |
be better: They can still come up with patches anyway, i.e. |
73 |
they are not even excluded from development if they do not use |
74 |
your framework. |