Improvement ideas for kernel and the surrounding oekosystem

[Bastian Blank <waldi@debian.org>]

Hi folks

I'd like to propose some pretty drastic reshaping of the way kernels,
initrd and bootloaders interact with each other and with dpkg.

Traditionaly we install kernel images and configs into /boot.  During
installation we generate files in /boot (and housekeeping in /var/lib).
Setup symlinks, sometimes in /boot, sometimes in /.  This is then used
by bootloader scripts to generate something bootable.

This poses several problems:
- We still have bootloaders without config generation, aka it relys on
  symlinks and may even break on runtime if they are changed.  But
  symlinks and bootloader setup are not handled by the same package.
- A lot of bootloaders require special filesystems or other settings.
  Now this more and more clashs with dpkg, as dpkg can't write data on
  those filesystems (FAT for EFI is a common example).
- You need to know what you want to boot and need to install your system
  accordingly.
- It does not fit anywhere in the regime of /usr-merge.

So my rough ideas would be:
- Everything from kernel packages is installed somewhere in /usr/lib.
  Aka the images itself and, if we got to it, pre-built initramfs and
  even unified images (initramfs integrated).
- Everything generated on installation by e.g. initramfs generators is
  put somewhere into /var/lib/.
- The bootloader stuff is responsible to put everything where they want
  to have it.  So those can tightly control what they need setup in what
  way.

How it could like like:
- /usr/lib/kernel/linux_5.14.0-1-amd64
  - kernel (linux can boot efi, bios and xen)
  - (initramfs.$package)
  - (kernel.efiunified)
- /usr/lib/kernel/xen_4.14
  - kernel.pcbios
  - kernel.efi
- /var/lib/kernel/linux_5.14.0-1-amd64
  - initramfs.$package (you could have multiple initramfs generators
    installed)
  - data.$package

The interfaces:
- kernel tells installed initramfs generators to do their magic on a
  single kernel
- kernel tells installed bootloaders to do their magic on a single
  kernel
- initramfs on installation wants to build all initramfs
- bootloaders on installation want to do their magic

All the tracking and signaling should be in one package.

What are your thoughts about that?

Regards,
Bastian

-- 
Schshschshchsch.
		-- The Gorn, "Arena", stardate 3046.2