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

[Kumar Appaiah <a.kumar@alumni.iitm.ac.in>]

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
two-fold:

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
though.

Thanks.

Kumar
-- 
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