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

Andreas Hasenack andreas at
Tue Jan 16 16:33:52 UTC 2024


On Tue, Jan 16, 2024 at 3:02 AM Steve Langasek <steve.langasek at>

> On Fri, Jan 12, 2024 at 11:05:24AM -0500, Nick Rosbrook wrote:
> > Hi,
> > > 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?
> > We have the concept of "quirks"[1] in ubuntu-release-upgrader which
> > allows us to handle special cases like this. For example, a cycle or
> > two ago when flatpak was removed from flavor seeds, we added some code
> > to not auto-remove flatpak if it appeared the user was actively using
> > it. So yes, if nothing else we could add a quirk to make sure
> > samba-vfs-modules-extra is installed upgrades if samba-vfs-modules is
> > currently installed.
> I want to weigh in here to say that I think we should NOT do this by
> default.
> In my view, every difference between "Install Ubuntu release X; upgrade to
> Ubuntu release X+1" and "Install Ubuntu release X+1" is a bug.
> These bugs vary in severity, and we'll probably never zero out the list of
> such bugs.  But we should not knowingly *introduce* such bugs through
> quirking.

Something I could to to gather data is to do an actual deployment using
glusterfs (of samba and qemu), upgrade, lose the gluster modules, and see
what happens.

If do-release-upgrade fails outright (because some postinst failed due to
the missing gluster module), then I guess it's a high prio bug and we
should proceed with the do-release-upgrade quirks.

If the upgrade finishes, the system reboots, and then services don't come
back up due to the missing glusterfs modules, and that can be fixed by just
an "apt install <pkg>", then it's less severe and can be release-noted. But
the quirk would also solve this situation, and I thought it wouldn't be
such a bad approach.

> This should also apply to "Install Ubuntu release X; apt install Y; upgrade
> to Ubuntu release X+1", when not modifying any configuration files along
> the
> way (though the severity of such a bug should also understandably be
> lower).
> If it's possible to detect that the system in question is *using*
> glusterfs,
> and add a quirk at runtime to install samba-vfs-modules-extra, then I think
> this sort of change is ok.  Otherwise, I think the right answer here is:

I admit that I was thinking about just checking if `samba-vfs-modules` is
installed in noble-1, and then mark samba-vfs-modules-extra for

I can do *some* detection of glusterfs usage via testparm[1] on the main
config file, but it will miss some cases:
- included dynamic files, like "include = /etc/samba/%U.conf" (which file
that will be is not known before an actual connection to the share)
- registry-based configurations (due to my lack of experience in that, I
suppose `sudo net conf list` would list it all)

And registry-based[2] happens to be the preferred way to configure a
clustered samba server (with glusterfs as the backend).

This is of course way more complex than the first approach.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ubuntu-devel mailing list