kernel.spec kernel-install integration

[Peter Jones]

On Thu, Apr 04, 2013 at 07:48:14AM +0200, Harald Hoyer wrote:
> Hi Josh,
> 
> as mentioned on IRC, here is the patch for the rawhide kernel.spec.
> 
> This patch is part of an upstream coordination, intended to unify the various
> ways distributions handle:
> 
> - installation of kernels in the system
> - create the matching initrds; hooking up the various implementations of
>   initramfs generators into the kernel package installation process
> - optionally/automatically create bootable rescue images to be able to recover
>   from failures:
>   https://fedoraproject.org/wiki/Features/DracutHostOnly
> 
> All the above functionality is provided by the “kernel-install” tool:
> http://www.freedesktop.org/software/systemd/man/kernel-install.html
> 
> It features:
> - flexible hookup/plugin directories to manage kernel installation and
>   uninstallation. initrd, bootloader, rescue image management, all plug into
>   that facility.
> 
> - strict separation of distribution-supplied logic and local customization
>   logic; system administrators are able to overwrite and replace/extend any part
>   of the default logic if needed
> 
> - hide distribution-specific logic behind a standardized command line interface
> 
> - unify the custom kernel installation from the source tree with the usual
>   kernel package installation; like the current /sbin/installkernel

Is there git repo for this other than just the normal systemd repo?
When I look there right now I don't see very much - it looks like it
only handles gummy-boot - before we do this, what's the plan for all the
architectures we support that /don't/ work with gummy-boot style configs?
Right now that's basically everything except x86, and even that isn't
really fully fleshed out yet.

Too be honest, kernel-install as it stands is a bit distasteful - what's
the point of breaking everything out into plugin directories if you're
not going to handle generation of /boot/loader/entries through a plugin?
That means if you're hacking on it or just trying to figure out what
happened on a machine, you have to go looking at both the plugin
directory and the script that runs it.  All of the stuff to manage
/boot/loader/entries should be moved into a plugin to avoid that.

It should be possible to re-factor new-kernel-package to be something we
can run from your plugin directories, but we should talk about what that
looks like before we do something like this to the kernel package and
simply break everything.

-- 
        Peter