kernel.spec kernel-install integration

[Josh Boyer]

On Fri, Apr 05, 2013 at 02:13:18PM +0200, Harald Hoyer wrote:
> 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.

So while things aren't going to break, this doesn't really address
Peter's question of why the loader entries aren't also handled via
plugins, does it?

I'd like to get some resolution on this by 3.10-rc1 so we can get it
into rawhide, but it does seem like a fair question.  Maybe I missed the
answer somewhere.

josh