1 |
Hello, list. |
2 |
|
3 |
I just took maintenance of some ebuilds which require user to patch |
4 |
kernel, e.g. l7-filter. Actually l7-filter is the ebuild which only task |
5 |
is to patch kernel and I really hate the way it works: |
6 |
* it requires FEATURES="-sandbox" |
7 |
* you have to reemerge l7-filter after each kernel update |
8 |
* and other similar problems the root of which is that portage never |
9 |
knows a kernel version the patch was already applied to. |
10 |
|
11 |
So I'm thinking on solution to fix this problem. First I've tried to |
12 |
rewrite ebuild to avoid FEATURES="-sandbox" and this is possible, but |
13 |
does not fix other problems. |
14 |
|
15 |
The best idea I could think of to the moment is similar to webapps. |
16 |
emerge just installs patches to some known location while actual |
17 |
patching will be done with some external utility - kernel-patcher. |
18 |
Together with patching it will populate database with information about |
19 |
patches to which kernels were installed. So if user decides to find out |
20 |
what patches were installed to the kernel kernel-patcher will list that. |
21 |
Also if user decides to upgrade kernel it'll be possible to call |
22 |
kernel-patcher and suggest user to install patches, applied to currently |
23 |
symlinked (/usr/src/linux) kernel too, thus simplifying kernel upgrade. |
24 |
|
25 |
Well, I did not wrote all details I have in my head now, but before I've |
26 |
started to work on/draft this this I wanted to hear some opinions as I'm |
27 |
sure some of you already have thoughts about this. Is this feasible |
28 |
solution? Are there better? |
29 |
|
30 |
-- |
31 |
Peter. |