Re: Possible future apt changes: release upgrades

On Tue, Mar 03, 2026 at 11:05:59PM +0100, David Kalnischkies wrote:
> Am Tue, Mar 03, 2026 at 06:33:23PM +0100, schrieb Julian Andres Klode:
> > > - 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 :)
> 
> fwiw I meant things that have no clear upgrade path, like say:
> ROM: emacs: dead upstream, low popcon, alternative: vim, kate, writer…

Yeah so the way it works now:

If emacs is automatically installed due to say Depends: text-editor;
apt considers it obsolete and will push it to the end of the provides
list. It will then go and install another text editor.

If emacs is manually installed, it's protected from being removed
in a dist-upgrade; but also not considered obsolete here, so it
won't go and try to install anything else regardless of whether
there's a dependency.

But yes, there's plenty of cases missing; and apt release-upgrade
should look at a list of obsolete packages and suggest removing or
marking them automatic.

> 
> I don't consider 'obsolete' to really cut that here as this hides
> important things the user uses inside a sea of old library versions
> that they could more or less easily autoremove without issues.
> 
> Also, if the user has e.g. stable in its sources it takes ages for
> a package to be considered 'obsolete' as its still somewhere.

FWIW, this is an interesting thing that I think I've handled in the new
solver but need to refactor out of it into the policy and pattern code:

The solver doesn't just have classic ?obsolete handling, but it also
has an obsoleted-by-newer-source-version; where it:

1. determines the candidate for the binary package
2. determines a candidate for the source package of that candidate
3. checks if the binary is still built by the source package candidate

This allows is to aggressively improve upgrade performance in
transitions for testing/unstable users, or your oldstable to stable
example.

> 
> And lastly it teaches users to hold the package, which is not usually
> a good strategy for reasons they don't know without digging.

I think holds are a lot less needed now with the new solver protecting
manual packages a whole lot more; it will only ever remove them during
install/remove operations if it cannot find any other possible solution.

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