Moving installkernel and mkboot from debianutils
Hi,
Firstly, I do not think that installkernel and mkboot scripts
are essential in any way any more (they were back in '97, though). Most
Debian installations, using either official kernel images, or using
kernel-package, have never run either -- which kinda goes against the
whole "Essential" meme.
The installkernel script is beginning to show its age, and does
not match how other packages cooperate in the installation of kernel
images in recent (like, for the last few) releases of Debian.
The installkernel, when run by root, runs mkboot by default,
which talks about the importance of boot floppy diskettes (I don't even
have a floppy drive anymore), and tries to run or not run lilo and
elilo based on heuristics (are they installed, is grub installed -- I
can have grub installed and yet still use lilo, but that is not
something considered), I have tried using the current installkernel
script as an end user, and the behaviour was not something I consider
desirable.
installkernel also unconditionally creates symbolic links in
$DESTDIR (nominally /boot). The symlinks created are:
$DESTDIR/{config,System.map,vmlinu[xz]}
These symlinks are not useful if you use grub, or use official kernel
images. Creating these links make it less useful when used to create
kernel image packages. (running mkboot is even worse when building a
kernel image package).
Ideally, the symbolic links should be updated if they exist, but
should not be created when they do not. I have a tested version of
installkernel that does not call mkboot, and only updates symblinks,
but doe4s not create them.
Next, the modern Debian installation has kernel images run
scripts which have been dropped into /etc/kernel/{pre,post}{inst,rm}.d/
directories, or put into /etc/kernel-img.conf -- and installkernel does
not do anything like this.
Now, when installkernel is called (by running make install in a
kernel source directory), the modules might not yet have been
installed, so running the scripts would be wrong (intramfs, for
instance, depends on the modules being around)/
I have suggested a common configurekernel script to accompany
installkernel, which is aware of the modern methods of triggering
actions when a new kernel image is installed, and have a script that
is undergoing testing, but that script would not be essential either.
I am proposing that we move installkernel, mkboot, and the new
configurekernel script into a new package, kernel-utils. and that
kernel-utils Replaces: debianutils, and during the transition period,
debianutils depends on kernel-utils.
The former action can be taken first; and the latter deferred
until the release team deem it safe.
Since Essential is frozen, I am asking if we can go forth with
this move.
The driver for this is kernel-package. Early in the game, there
was little support for creating kernel images in the kernel sources,
and kernel-package went down the path of running a build, and picking
the files to install into image and header packages, by enumeration,
since that was the only thing it could do a decade ago.
Things have changes, and the kernel Kbuild has options to
install headers, modules, and even images (using installkernel), and
since these convenience calls exist, there has been a great deal of
fluidity in the location and number of files that needed to be
installed -- and kernel-package would need whole swaths of conditional
code to work with different versions, if it does not use the provided
front ends.
I would like to use intallkernel to build kernel images, since
then I can use Kbuild interfaces to create the kernel packages, and
greatly simplify kernel building, and make it more robust.
manoj
--
Success is getting what you want; happiness is wanting what you get.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: