kernel.spec kernel-install integration

[Harald Hoyer]

Am 04.04.2013 22:17, schrieb 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.
> 

We want to have a distro agnostic API for installing the kernel. new-kernel-pkg
is fedora only and with systemd we provide tools for every distribution.

dracut (also not fedora-only) already ships with a plugin for kernel-install.

Other distributions start to make use of kernel-install right now.

Changing the fedora kernel.spec today would not *break* anything, because
kernel-install is currently patched in fedora to call new-kernel-pkg.
http://pkgs.fedoraproject.org/cgit/systemd.git/tree/kernel-install-grubby.patch

It would be great to convert grubby to hook into the kernel-install callouts
instead of being called from new-kernel-package, but this is an optional next
step, that you would need to decide on, if you agree. It does not affect the
introduction of kernel-install at this point, nothing should break.