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.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e389689.30...@sbcglobal.net
