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. :) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50f6a3b3.1060...@bahj.com
Re: Packaging a Patched Kernel
I would suggest that you take a look at the existing Linux patch packages in Debian: pabs@chianamo ~ $ aptitude search '(kernel|linux)-patch' p kernel-patch-atopacct - save additional statistical counters for atop in the record p kernel-patch-atopcnt - additional statistical counters for atop p kernel-patch-scripts - Scripts to help dealing with packaged kernel patches p kernel-patch-viewos - View-OS - Kernel patch for better UMView performances p linux-patch-debianlogo- Display a Debian logo on a framebuffer device at boottime p linux-patch-grsecurity2 - grsecurity kernel patch p linux-patch-lustre- Linux kernel patch for the Lustre Filesystem p linux-patch-tuxonice - TuxOnIce (aka suspend2) kernel patch p linux-patch-xenomai - Linux kernel patches for Xenomai -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6GhDFF7PK=s9jxqengrosyybp20shzfpnhgxqocpwh...@mail.gmail.com
Re: Packaging a Patched Kernel
I would suggest that you take a look at the existing Linux patch packages in Debian: pabs@chianamo ~ $ aptitude search '(kernel|linux)-patch' p kernel-patch-atopacct - save additional statistical counters for atop in the record p kernel-patch-atopcnt - additional statistical counters for atop p kernel-patch-scripts - Scripts to help dealing with packaged kernel patches p kernel-patch-viewos - View-OS - Kernel patch for better UMView performances p linux-patch-debianlogo- Display a Debian logo on a framebuffer device at boottime p linux-patch-grsecurity2 - grsecurity kernel patch p linux-patch-lustre- Linux kernel patch for the Lustre Filesystem p linux-patch-tuxonice - TuxOnIce (aka suspend2) kernel patch p linux-patch-xenomai - Linux kernel patches for Xenomai Thanks for the reply. My understanding of the kernel patch packages was that they were a way of distributing kernel packages so that kernel developers could later include them in a Debian packaging project. Am I correct? It seems that this would be a good way of distributing the patch I have chosen to use, but it doesn't seem to help with deriving a new kernel package from an existing one. In essence, my concern is the following. Suppose I have built a new kernel package using make-kpkg, pulled in the patch set the Debian kernels are using, and added the bcache patch as well. If the Debian kernel developers add a new patch, the kernel I'm building won't include it. This is the reason I'm trying to derive my kernel package from an existing Debian kernel package: I'm assuming that anything out of the Debian repo is the latest and greatest and I just want to drop bcache on top of it. That said, the process of explaining this has helped me understand why I'm not exactly in the Debian packaging mainstream. I think I'll keep doing what I'm doing until it breaks (or until I find out that I'm breaking policy in some way). Does anyone have any thoughts about the distribution issue? Are there any special rules a third-party package repository should follow w.r.t. their packages' distributions? Thanks, Zach -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50f6b942.20...@bahj.com
