Re: Is there a good solution for this: release-upgrade with dependency moved to universe
Hi, On Tue, Jan 16, 2024 at 3:02 AM Steve Langasek wrote: > 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 ", 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 installation. 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. 1. https://manpages.ubuntu.com/manpages/mantic/en/man1/testparm.1.html 2. https://wiki.samba.org/index.php/Configuring_clustered_Samba#Using_the_Samba_registry -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Is there a good solution for this: release-upgrade with dependency moved to universe
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. 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: behavior changes on upgrade between releases, and the release upgrade is the time for the user to discover this is the case and deal with it (as part of a maintenance window). Otherwise, you're really just shifting the pain. Ubuntu X went EOL, I have to reinstall, I install Ubuntu X+1 which is what I had installed before, why are things behaving differently?! -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Is there a good solution for this: release-upgrade with dependency moved to universe
On Mon, Jan 15, 2024 at 06:09:07PM -0300, Andreas Hasenack wrote: > Hi Nick, > > On Fri, Jan 12, 2024 at 1:05 PM 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. > > > > > That sounds exactly what I need, thank a log for the pointer! > > Is there an easy way to use "do-release-upgrade -d" to test my changes > before proposing them, or will it always download the tarball at > http://archive.ubuntu.com/ubuntu/dists/noble/main/dist-upgrader-all/current/noble.tar.gz > and use that? "do-release-upgrade -d" will always download the tarball that the appropriate meta-release file indicates. However, you could build the package locally put and extract the tarball on the system to be upgraded and run "sudo ./noble" to test your changes. It is important to note that "do-release-upgrade" does pass some environment variables along to the upgrade process that would be lost with this method. -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Is there a good solution for this: release-upgrade with dependency moved to universe
Hi Nick, On Fri, Jan 12, 2024 at 1:05 PM 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. > > That sounds exactly what I need, thank a log for the pointer! Is there an easy way to use "do-release-upgrade -d" to test my changes before proposing them, or will it always download the tarball at http://archive.ubuntu.com/ubuntu/dists/noble/main/dist-upgrader-all/current/noble.tar.gz and use that? > Thanks, > Nick > > [1] > https://git.launchpad.net/ubuntu-release-upgrader/tree/DistUpgrade/DistUpgradeQuirks.py > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Is there a good solution for this: release-upgrade with dependency moved to universe
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. Thanks, Nick [1] https://git.launchpad.net/ubuntu-release-upgrader/tree/DistUpgrade/DistUpgradeQuirks.py -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
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. 1. https://launchpad.net/bugs/2045063 2. https://wiki.debian.org/PackageTransition -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
