[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Moving installkernel and mkboot from debianutils


        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

        installkernel also unconditionally creates symbolic links in
 $DESTDIR (nominally /boot).  The symlinks created are:
 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.

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: