Rejuvenated kernel-package uploaded to unstable, please test
A new version of kernel-package has made its way to unstable.
This is a extensive change, and addresses most of the problems that
have been plaguing kernel-package, partially thanks to patches provided
by other folk.
The new version works with the merged x86 code in recent
kernels, while retaining compatibility with older kernel sources. It
correctly generates the right set of headers. It is again
cross-compilation friendly. The postinst no longer runs lilo when it
thinks there is no other bootloader (it used to detect grub, but not
grub2). It correctly installs firmware in a versioned location under
More significantly, the build system has moved to a more
streamlined, make -j friendly build system While I am not sure of this
fixes some of the nagging problems we have been facing in recent
versions of kernel-package, where we used double colon rules, which
were convenient, sure, but played havoc with ordering of the rules, and
had to have various band-aids to help out with the ordering. The system
was rapidly growing complex, with clear indication that it was actually
The new target mechanism does away with doublecolon rules, and
should play better with parrallel compilation. We try to use upstream
kbuild as far as possible, to reduce churn as the files upstream
installs change. Some added checks of the Makefile are now in place so
we retain backwards compatibility. This should improve things lot wrt
header files. We also now add dependencies to more packages actually
required to build kernel images.
We also try to look for the kbuild created KERNELRELEASE
variable, which is designed to be used by distros to figure out where
modules are to be loaded from, etc. This should help reduce version
mismatches. We also prepare the kernel.release file early, to help
We also refitted to support the new XEN code in mainstream, in
that the same image can be booted normally or be used as a XEN
image. This support probably needs to be improved.
The make target dependencies have been extensively reworked, to
minimize surprises and wasted effort. We also strip modules, based on
Extra care is now taken so we do not accidentally remove
./debian while cleaning, thanks to upstream helpfully removing ./debian
when cleaning. This should prevent dpkg-buildpackage from accidentally
shooting itself in the foot by removing ./debian as its first action.
Finally, the changes have made it possible to create a
kernel-image straight out of a git working directory, partially because
the upstream script does not think that the changes kernel-package
makes to the source make it dirty, and partially because we run the
kernel.release creation script early, just after patching the
sources, but before generating the ./debian/changelog, and this,
abetted by using KERNELRELEASE, ensures that we correctly capture the
I have also added dependencies to kernel package, the kerel
source package, the kernel header package, with the basic tools
required to build a kernel, so by installing the source package, or the
header package, the user should have most of the things required to
compile their own kernel.
Anyway, this was a marathon two day hack session, and while I
have compiled 184.108.40.206 and 2.6.26 several dozen times, I would
appreciate testing this version, so we may get it into lenny.
Dungeons and Dragons is just a lot of Saxon Violence.
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C