Is there a good solution for this: release-upgrade with dependency moved to universe
Andreas Hasenack
andreas at canonical.com
Fri Jan 12 15:51:05 UTC 2024
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.
1. https://launchpad.net/bugs/2045063
2. https://wiki.debian.org/PackageTransition
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20240112/73093fa7/attachment.html>
More information about the ubuntu-devel
mailing list