Hi,
given the recent flamewar about the new attempt to package the linux
kernel here are some ideas that surfaced during several discussions on
irc. I want to draw a conclusion here for intrested people who missed
it and for future references.
First some basically already existing stuff:
1. there should be a kernel-source-linux/bsd/hurd/whatever-version
package that it the upstreams pure vanilla source.
2. Each architecture and debian in general should have a patches
relative to that and metapackages to provide a kernel tree. Thats
already there for most archs (all but 2 afaik).
3. Additional patches can be packages up the same way the arch
specific and general debian patches are done.
Currently kernel-package handles that quite good already. Thats all
already available and discussion of the above should be kept out of
here (unless relevant to the ideas below).
Now some new ideas (on which comments and suggestions are welcome):
A) Simplify kernel-image packages, less repetitions
I sugested to make kernel-package contain all the scripts and rules to
build a kernel-image package just like cdbs contains all the basic
stuff to build a deb. The kernel-image package would just contain the
config to be used, specify what patches are involved and any rules
that are uncommon or unforseen by kernel-package.
The unpacking, patching, configuring, stampfiles, etc in the current
kernel-image packages is allways the same and can be handled by one
include statement.
B) Less bug propagation from kernel-package to kernel-images
Now make-kpkg adds pre/postinst/rm and similar files to the
kernel-image packages that handle updating the kernel when installing.
Any bug or change in those scripts requires a complete rebuild of the
kernel-images.
Eduard Block suggested removing the update scripts from the
pre/postinst/rm scripts and adding a "update-kernel" tool that handles
installation and removal of kernels. update-kernel can be fixed or
changed without rebuilding all kernel-images. bootloaders could
provide their own update-kernel scripts (or hook into it) that modify
the menus or just rerun the bootloader whenever the kernel changes.
I too think having a central control point for kernel installs and
removals would be a good idea.
[Note: Even grub needs to update its menu.lst for each kernel if the
correct version is to be shown as title]
C) Reduce the traffic and mirror space for kernel updates, split
modules into groups
Splitting the kernel image itself and the modules into seperate debs
would save a lot of space for powerpc (which has 3 kernel flavours
that can share modules).
Further splitting of the modules into groups (ide-modules,
scsi-modules, net-modules, multimedia-modules,...) was suggested.
Debian-installer has code for splitting up modules into udebs and that
could be reused. One big downside I see with this further splitting is
that users would complain about unsuported hardware because they
didn't install the right module debs.
Personally I'm against splitting up modules into several debs but for
splitting kernel image and modules.
D) Updateable custom build kernels
Many people prefer to configure and build their kernels themself,
mostly because they don't need all the stuff the debian kernel
provides. The drawback is that updates of patches (security fixes?)
need to be tracked manually and a new kernel build manually. People
might have to build several kernel images for each source/patch update
or distribute one kernel image to several systems.
What I propose is a 2 step system that will automate (or through
pining onmly manual updates) these steps.
A package (say kernel-linux-setup) provides a setup utility the user
(group kernel or some other restriction) can use to create a kernel
config of his taste. That would include not only the .config file but
also the set of patches to be used and how flexible updates should be
(e.g. allow 2.4.22-1 to 2.4.22-2 updates only or 2.4.22 to 2.4.23
updates?).
The setup utility then creates a kernel-compile-<name of config>
package that depends on the right kernel-source, kernel-tree, patches,
utilities and contains the config needed. That package can then be
installed (by the utility?) and hooks itself into any updates of the
kernel source, tree or patches so it gets reconfigured every time they
are updated. That solves the problem of tracking source and patch
updates.
The kernel-compile-* package(s) can rebuild the kernel-image every
time they are configured directly, in the background or mark the
rebuild to be done by a cron job. Problems (like new config options)
could be asked directly (for direct build) or reported via email. The
default answere could be accepted or the build could fail.
After compilation we have a kernel-image-*.deb but what to do with it?
When the image is compiled directly dpkg is still running so it can't
be installed with dpkg itself. Installing it directly (not build a
deb) is somehow bad too. When the image is build in the background or
by cron it could be installed automatically but thats dangerous. The
user might even unknowingly decide to reboot in the middle of the
kernel upgrade.
Here is where the "2 step system" comes into effect. The
kernel-image-*.deb would be put into a local repository. Older version
could be rotated out (keep the last X kernels or other schemes). The
next time "apt-get update; apt-get upgrade" is run the new
kernel-image will be installed. Exporting the repository via
nfs/ftp/http to a pool would allow every system to apt-get the new
kernel on the next upgrade. Allowing for multiple "kernel-compile-*"
packages a pool with different custom kernel-images (e.g. server and
client config) could be managed easily.
By setting the pin of the local repository below 100 an accidental
update to newer kernels could be prevented while still alowing a
manual "apt-get install kerne-image-foo" to update. That can even be
done on a host by host basis.
Ideas, comments, suggestion?
MfG
Goswin
