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. _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
