Currently the Solus kernel management is highly limited and very flaky.
In essence, we have a single kernel package (along with kernel-modules subpackage) that contains the entire target filesystem as it would be when installed.
Effectively, this limits us to hardcoded paths, and a single kernel type.
Additionally, this has the disastrous effect that upon upgrading the kernel to a new release/version, the existing kernel and modules are permanently removed from the filesystem.
This makes kernel upgrades entirely one way. Due to the current setup, we have various triggers running in several packages in what we hope is a sane order, which also results in breaking
the update-grub process. This is usually down to the fact that the ntfs kernel support is no longer present, so the Windows partition cannot be scanned. (If the module is already loaded then it continues fine.)
The proposal is to remove the current broken system, and implement clr-boot-manager.
kernel-modules and kernel will be replaced, on upgrade, to linux-lts (At 4.9.1)
A single new package will be provided for the integration triggers, which will invoke clr-boot-manager upgrade, and also linux-driver-manager when it is done.
Important to note is that the modules + kernel objects are tagged with permanent="True" in the metadata, so that they are not removed on
upgrade. They move into clr-boot-manager's domain.
Resolving this will unblock numerous issues, subtasked as appropriate.