> That won't work, since the old images still are available (and > therefore won't cause a conflict).
I don’t understand your objection. Note that the goal is not to conflict with any kernel image packages, but only with new versions of the linux-image-generic _metapackage_, which is responsible for causing new ABI-incompatible kernel image packages to be automatically installed. I know that this strategy works, because we have successfully used it for openafs kernel modules in the Debathena project <http://debathena.mit.edu/>. > Apart from that, a missing kernel module (from universe) should > not block a security kernel update. No upgrades will be blocked unless the user installs the virtualbox-ose- modules-generic package, which is as good an indication as any that the user _needs_ a kernel with virtualbox modules, and a security kernel update that comes without modules is worse than useless for them. If the user wants to make a different choice, they can either install virtualbox-ose-modules-2.6.26-3-generic instead of virtualbox-ose- modules-generic, or they can install linux-image-2.6.26-5-generic anyway when it becomes available (since only the linux-image-generic metapackage is held back). Even a user that does install virtualbox-ose-modules-generic will see that the new kernel upgrade is available. I’ve tried this with apt-get, aptitude, synaptic, adept, and update-manager—they will all notice the conflict, and either report that updates were held back, or propose resolving it by removing virtualbox-ose-modules-generic. In either case it should be clear what’s going on. This is infinitely better than the current solution which will silently break packages that the user wants to use. -- Should ship new kernel modules at same time as new kernel https://bugs.launchpad.net/bugs/253831 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
