[gentoo-kernel] Kernel patching solution.

[gentoo-kernel] Kernel patching solution.

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]

Hello, list.

I just took maintenance of some ebuilds which require user to patch
kernel, e.g. l7-filter. Actually l7-filter is the ebuild which only task
is to patch kernel and I really hate the way it works:
 * it requires FEATURES="-sandbox"
 * you have to reemerge l7-filter after each kernel update
 * and other similar problems the root of which is that portage never
knows a kernel version the patch was already applied to.

So I'm thinking on solution to fix this problem. First I've tried to
rewrite ebuild to avoid FEATURES="-sandbox" and this is possible, but
does not fix other problems.

The best idea I could think of to the moment is similar to webapps.
emerge just installs patches to some known location while actual
patching will be done with some external utility - kernel-patcher.
Together with patching it will populate database with information about
patches to which kernels were installed. So if user decides to find out
what patches were installed to the kernel kernel-patcher will list that.
Also if user decides to upgrade kernel it'll be possible to call
kernel-patcher and suggest user to install patches, applied to currently
symlinked (/usr/src/linux) kernel too, thus simplifying kernel upgrade.

Well, I did not wrote all details I have in my head now, but before I've
started to work on/draft this this I wanted to hear some opinions as I'm
sure some of you already have thoughts about this. Is this feasible
solution? Are there better?

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-kernel] Kernel patching solution.

[Daniel Drake]

Peter Volkov wrote:
> Well, I did not wrote all details I have in my head now, but before I've
> started to work on/draft this this I wanted to hear some opinions as I'm
> sure some of you already have thoughts about this. Is this feasible
> solution? Are there better?

I hate l7-filter and wish it would go away.

I would not suggest spending time on the problem, as if I hear that 
someone else is going to add a package that does something similar, I'll 
go and behead them.

As for other options: You could just install the patch to the filesystem 
and require the user to apply it. Other packages do/did this, e.g. hdaps

But the only real solution is this: get the patch merged upstream, or 
equivalent functionality offered in the mainline kernel. Everything else 
is working against the flow of the kernel.

Daniel

-- 
gentoo-kernel@gentoo.org mailing list

Re: [gentoo-kernel] Kernel patching solution.

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]


В Чтв, 27/12/2007 в 21:05 +0000, Daniel Drake пишет:
> As for other options: You could just install the patch to the filesystem 
> and require the user to apply it. Other packages do/did this, e.g. hdaps

Ok. Let's me suggest another way. I'd like to standardize (eclass) the
place such ebuilds install patches. Together with place, I'd like to add
information (may be in patch name or inside patch itself) what kernels
this patch supports. Is this the way to go?

After this I'm sure there will be no problem to have external tool to
simplify patching. If you do not like it - do not use it.

> But the only real solution is this: get the patch merged upstream, or 
> equivalent functionality offered in the mainline kernel. Everything else 
> is working against the flow of the kernel.

Eh. I see your intentions. But IMQ will never get upstream while me and
many other people are using it and AFAIK currently there is not
substitution for it (IFB is different). patch-o-matic patches are really
slow in moving to official tree, while I have to use it's functionality.
There will be always such patches.

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]