[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Packaging a Patched Kernel

Hi, there.  I'm not an official Debian maintainer, but I'm building a custom
Debian kernel based on the bcache fork by Kent Overstreet
(http://bcache.evilpiepirate.org/). I've read through the relevant-seeming part
of the Debian Kernel Handbook and I think I have a build process in place.

This isn't quite as simple as dropping a new patch file in because I want to be
able to produce a package for the latest Debian Linux kernel with the latest
bcache changes patched in. So I've written a script that (1) gets the latest
kernel source via apt-get source linux, (2) generates a bcache patch using the bcache git repo, (3) drops the patch into the Debian kernel sources using quilt,
and (4) builds the kernel. bcache changes the kernel ABI and I don't want to
have to linearize a versioning scheme for that, so I'm using an ABI number based
on the bcache git repo timestamps (prefixed, of course, with "bcache").

So my first question is: is there a better, more sane way to do this? I don't view this as a single fork from the official Debian kernels as much as I do a patch to each of them. It just seems that there should be a simpler way to have Debian build a patched kernel for me. (I know that Section 4.2.2 of the Kernel Handbook describes a way to test patches, but I was looking for something a bit
more distributable than that.)

My second question revolves around distribution. I might want to throw these
packages into a Debian repository of my very own to save other people the
effort. Should I be marking my kernel packages as experimental in the changelog? I doubt I'm supposed to use "UNDISTRIBUTED", but I can't seem to find anywhere that talks about which distributions should be used by third-party repository
maintainers.  If I do mark them experimental, is there a good way to version
them? Using the required versioning scheme for experimental package names, I'd have to use a version like "3.7.1-1~experimental", but I'm not sure if it's okay to use a version number like that with my packages. (I *will* be using an ABI number like "bcache-2013.01.11", so it won't collide with existing packages; I
just want to know if that version number is okay.)

Thanks much for reading. I'm sort of diving into this head-first. I don't expect that my packages will ever be mainline (or as polished or nice as the mainline packages are), but I wanted to throw together a solution for using bcache until it is merged into the mainline Linux kernel (if it ever is). And now that I've
gone to this much effort, I sort of feel like amortizing that cost. :)

Reply to: