Comment 4 for bug 253831

> 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.