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

2024-01-15 Thread Steve Langasek
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

2024-01-15 Thread Brian Murray
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

2024-01-15 Thread Andreas Hasenack
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