Comment 2 for bug 2045063

There is a general release-upgrade problem to consider here.

Let's say you have samba installed on mantic, and are using glusterfs. The glusterfs module comes in the samba-vfs-modules package, which is in main.

In noble we then split that module out to bin:samba-vfs-modules-glusterfs, and place that in universe. There is no dependency between bin:samba-vfs-modules(main) and bin:samba-vfs-modules-glusterfs(universe).

If you release-upgrade from mantic to noble, you will get the new bin:samba-vfs-modules(main) which does not have the glusterfs module, and your samba installation will likely break.

You can still install it, and unbreak your system, but do-release-upgrade might have failed already (because postinst failed to restart samba, for example, given the module is not on disk anymore), or at least you will have a broken noble installation for a while.

And I don't see a way to pre-empt this problem. Even if you read the release notes, and become aware of this, there is nothing you can do *prior* to the release-upgrade to not be left with this broken upgrade.

Specifically for the samba case, I believe there will only be an error when the actual share which is using glusterfs is contacted, but this is still a general problem. For qemu, I don't know yet what the failure scenario is once we move the gluster module out of qemu-block-extra and release-upgrade. Keeping in mind that a reboot is needed after the release upgrade, I believe existing VMs using the glusterfs module would just fail to start.