Friday 12 January 2024

Is there a good solution for this: release-upgrade with dependency moved to universe

I have package bin:samba-vfs-modules which ships, among other things, a glusterfs module:

  /usr/lib/x86_64-linux-gnu/samba/vfs/glusterfs.so
  /usr/lib/x86_64-linux-gnu/samba/vfs/glusterfs_fuse.so

We intend[1] to demote glusterfs to Universe, and since bin:samba-vfs-modules is in main, one solution is to create another package, let's say, called bin:samba-vfs-modules-extra, with said glusterfs module, and ship that in universe.

That's case #7 of the package transition guide[2].

Due to this move, any upgrade from the old bin:samba-vfs-modules to the new bin:samba-vfs-modules will *lose* the glusterfs module. I cannot make one depend on the other because bin:samba-vfs-modules-extra is in universe, and as we all know, we can't have a package in main depend on one in universe.

Such a file move between packages will not happen in an SRU, but in the devel release. Which means users who were relying on an installation that used the samba vfs gluster module, and do-release-upgrade to noble, their samba server will likely break until bin:samba-vfs-modules-extra is installed. Of course this can and will be noted in the release notes, but even then, there is nothing the user could do before-hand to not encounter this problem, other than prepare, and know how to fix it after the upgrade is finished. Not a super nice experience.

I guess something in do-release-upgrade could be run to, when encountering such a situation, automatically select bin:samba-vfs-modules-extra for the upgrade as well? Is it worth it? Is there a precedence for something like this? And how would this be done in a more generic/general case, if at all?

Another option would be to move bin:samba-vfs-modules to universe, and deal with those consequences. Then I wouldn't need this specific package split.

In the end, this is still better than just dropping the glusterfs module from the build, which would leave users with no way out whatsoever.

I used samba as an example, but the same problem exists for qemu (which also ships a gluster storage driver), and in that case it would probably mean VMs not coming back up until the new (now in universe) package is installed.