Jan Henke <Jan.Henke@taujhe.de> (2014-09-26): > Am 26.09.2014 um 13:59 schrieb Steven Chamberlain: > > That would work, except any chroot or jail would install a kernel. I > > think, even sbuild running on the buildds would then install a kernel > > image and modules inside the build chroot, and that's obviously wrong. > > > > APT understands it should remove kfreebsd-image-9 but just doesn't know > > to install kfreebsd-image-10; I wonder if a Linux dist-upgrade from > > squeeze to wheezy pulls in linux-image-3.2 automatically, and how it > > does that? > > > > I know Linux packaging does show a prompt if you try to remove the last > > kernel image from the system; something similar would at least alert > > users if a dist-upgrade is going wrong, although there must be a way to > > fix this to do it right. > > > > Perhaps kfreebsd-image-10 needs to 'Provide' a newer kfreebsd-image-9 > > version (and adjust the Breaks to << that version), or something ugly > > like that? > > > > Regards, > Hi, > > as far as I know the main mechanism for Linux is to have a meta-package > like "linux-generic" which depends on the latest kernel version. On a > dist upgrade this package is updated to a new version, which depends on > the new kernel version. > > So for kFreeBSD the default installation would need to include a > "kfreebsd-image" or something package, which just depends on > "kfreebsd-image-amd64 | kfreebsd-image-686 " or something along the > line. So on a dist upgrade it should pull the new kernel package via > dependency resolution. > > I hope that makes sense when you read it. There are so many things wrong here, where do I start? First things first: it makes no sense whatsoever for a userland package to have any kind of relationships towards kernel packages. You can force stuff to be installed, upgraded, or removed, but that won't give you any guarantee about the *currently running* kernel. Trying to provide a kernel-image-9 package and playing with versions wouldn't work because you can't use versioned provides. Having a metapackage pulling a newer package would avoid letting the system without a kernel at all. But I don't think there's any such meta package in stable at the moment, so that wouldn't solve the upgrade problem at all! Having a prompt asking before removing the last/running kernel package to limit collateral damage doesn't seem too crazy but that doesn't address the main point. Which is: your userland package needs to support both kernel versions to handle the upgrade step. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature