Web lists-archives.com

Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware

Dear Daniel,

On Tue, Jan 23, 2018 at 01:34:32AM +0100, Daniel Reichelt wrote:
> Hi,
> what about ripping out the affected kernel modules and provide the
> patched sources in a separate package and have them built at install
> time via DKMS?
> In order to not interfere with the modules provided by the linux-image-*
> packages, you could
> - rename the kernel modules provided by your module package
> - add the original module names to a blacklist in /etc/modprobe.d
> - add your modules to /etc/modules-load.d/something
> - and finally add the blacklist and load list to your package as well.
> (An alternative to changing module names might be to use
> update-alternatives or dpkg-divert and just provide/integrate the
> renamed .ko files)
> The initial setup of the packaging/build script will require a bit of
> fiddling around but in the long run you'll be able to provide your users
> with updates much faster and without havingt to go through the
> time-consuming kernel build process. Moreover, the required storage and
> bandwith for the infrastructure holding your repository will be tiny
> compared to those for holding a full-blown kernel package.

Thanks for the idea. The reason we don't prefer this at the moment is

1. This would lead to "forking" some parts of the kernel source and
having to track them separately.

2. More importantly, we hope that this is a temporary measure, since
we hope that the patches will be eventuall upstreamed and the kernel
configs will also reflect the changes required.

If this becomes a longer term requirement, I will use your idea


As usual, this being a 1.3.x release, I haven't even compiled this
kernel yet.  So if it works, you should be doubly impressed.
		-- Linus Torvalds, announcing kernel 1.3.3