Re: Possible future apt changes: release upgrades

On Tue, Mar 03, 2026 at 02:31:36PM +0100, David Kalnischkies wrote:
> Am Tue, Mar 03, 2026 at 11:08:02AM +0100, schrieb Thomas Goirand:
> > d-private is probably not the best place to discuss this (feel free to move
> > this discussion somewhere else), but...
> 
> You could always move to [email protected] with ANY questions or what not.
> I just did with this reply, so if anyone replies please drop d-private
> (And note that I changed the subject for reasons)

Let's actually drop private.

> 
> 
> > > Release Upgrades
> > > - the `apt release-upgrade` command
> > 
> > What is this apt release-upgrade command doing? I really hope you're not
> > trying to push into Debian the upgrade command Ubuntu has, as we should
> > *not* rely on this type of thing to upgrade to stable+1. Why? Because we
> > also maintain testing and unstable, and with these, it makes no sense.

We try to smooth things over but we can't always do it; so we discussed
having the ability a year ago or so on #debian-release.

> 
> Well, yes and no. I could imagine various different things that could be
> changed/better/… in a stable to stable+1 upgrade that do not apply to
> testing/unstable like:
> - Where is it written that you have to manually adapt your sources
>   configuration with a text editor (graphical of course) that you
>   have to start as root to refer to stable+1 instead of stable ?
>   I mean… seriously?
> - If we recommend to run certain commands in order to avoid problems,
>   (like, first upgrade to latest point release, than do release upgrade)
>   why can we not just run them automatically in that order ?

This!

> 
> All the way up to things that are more prominent in a release upgrade,
> but apply equally well in unstable as well like:
> - the release notes, Debian.NEWS, … describe that some configuration is
>   phased out. Just that the folks who should read that usually don't
>   (or are not experienced enough to know it even applies to them)
>   and so are surprised by the next upgrade "surprisingly" breaking their
>   system.
>   (I got a LOT of feedback for the non-free-firmware split warning hack,
>    same for the FTP decommission earlier, that in a world where everyone
>    reads news, nobody would have seen.)
> - package foo (which provides a world-accessible security bugged server
>   component of course) is unmaintained and dropped from Debian. Maybe it
>   even has a 80% compatible alternative (or twenty). We hide this info
>   in the removal request to ftpmasters and hope that users will eventually
>   figure it out. Maybe. Lets hope they just reinstall.

The new solver is a bit silly there in that it will prefer to install
a replacement if it's pulled in via a dependency on say a virtual
package or or group :)

Some of these checks can be expensive, and doing them on each upgrade of
a testing/unstable machine would be crazy. People running testing or
particularly unstable always need to do with some level of craziness
and do some manual fix up potentially, but if we can help the less
excited and more anxious users with their stable updates, let's do it.

> Not sure if ANY of this is what Julian means with this bullet point.
> Not sure if ALL of this is apt or shouldn't better be done by <not-apt
> that doesn't exist (yet) but probably should(n't)>.

I think the way it goes is apt release-upgrade consults a quirks package
that it installs from the target release, then it upgrades itself, then
it can look at declarative quirks and potentially programmatic quirks
over varlink.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en