On 08/02/2011 07:45 AM, Stephen Powell wrote:
On Mon, 01 Aug 2011 22:44:46 -0400 (EDT), Dave Witbrodt wrote:My understanding is that the Debian Kernel Team recommends using the 'make deb-pkg' target now; they argued that kernel-package should be considered deprecated, but Manoj wanted to continue supporting it since so many people have used it for so long and there is nothing really wrong with it (until now, though it's probably easy to fix). I just finished building my first linux-3.0 custom kernel using the deb-pkg target, and everything works fine. (I frequently test cutting-edge upstream changes to the radeon driver and mesa, and these often involve changes to the radeon DRM in the kernel.) I was a long-time user of make-kpkg, but since I learned how to use the in-kernel deb-pkg target I have been taking the Debian Kernel Team's advice and recommending building custom kernels that way.Actually, the kernel team recommends yet another method, which involves downloading the source package with, for example, apt-get --only-source source linux-2.6 then using dpkg-buildpackage to build it. But that has a number of drawbacks. For one, only official Debian source packages (and usually, only the latest one, unless source packages are available at snapshot.debian.org) may be used. Second, the modified package usually replaces the stock package, and I like to keep my old kernel as a backout.
We're not really talking about the same thing. The "Debian Linux Kernel Handbook" includes both a method for building kernels identical (or nearly identical) to those produced by the Debian Kernel Team and a method for building custom kernels (which may vary greatly from Debian kernels). For those interested, the handbook is available on the web at
http://kernel-handbook.alioth.debian.org or can be installed via the debian-kernel-handbook package in Wheezy or Sid.No mention of 'dpkg-buildpackage' even occurs in ch. 4 of the handbook. (I do use 'dpkg-buildpackage' frequently to build other software packages, such as the X server, the radeon driver, libdrm, and mesa, but not the kernel.)
I use the method described in section 4.5 of the handbook (with some personal modifications, of course) even though I am often building kernels from upstream git repos. (Section 4.6 describes this, but simply refers back to the process in section 4.5 for the actual build once the sources are obtained and configured.)
I don't like "make deb-pkg" that well for a number of reasons. One of them is that I get a linux-headers-* package and a libc-dev package too, whether I want them or not. make-kpkg is more flexible. I only get the packages that I want.
I agree that this is a lack of flexibility. The reason I am not bothered by it is that the in-kernel deb-pkg target builds all of those packages extremely efficiently, and my Phenom II quad core builds my custom kernel and all of the DEB packages in just under 3 minutes when I build using 5 parallel processes. For me, your criticism here is quite underwhelming; you might simply file a wishlist bug report to see whether the Kernel Team is willing to provide some of the extra flexibility you are asking for.
> It may be considered deprecated by the kernel
team, but it is still supported by Manoj Srivastava, the upstream author
and Debian Package Maintainer for kernel-package. See
http://users.wowway.com/~zlinuxman/Kernel.htm
for a complete explanation of my kernel-building methodology and the
reasons behind it. You are of course entitled to disagree with me. ;-)
I've read it. I do disagree, but not strongly. I was grateful for the existence of 'kernel-package' and Manoj's work supporting it, and always will be. But times change, and having an in-kernel build target which produces DEBs means that breakage becomes an upstream problem instead of a Debian-only problem. The fact that 'kernel-package' cannot (for the moment) build 3.0 kernels while the upstream "deb-pkg" makefile target _can_ demonstrates the benefits of having the DEB build code in the kernel itself.
Your advice on wowway.com, in light of what I have argued above, seems somewhat outdated. My disagreement is only mild, though, and I would not steer anyone away from the procedure you describe if it is working for them; I would just give them different advice... if asked.
In Debian solidarity, Dave W.