[Aptitude-devel] Bug#934541: Bug#934541: aptitude: upgraded a package to experimental without notice, though SolutionCost has "safety" first

[Julian Andres Klode]

On Tue, Mar 18, 2025 at 03:17:08PM +0100, Vincent Lefevre wrote:
> Control: found -1 0.8.13-7
> 
> Still the same bug (or similar). A bundle is available at
> 
>   https://vinc17.net/aptitude-20250318.bundle
> 
> for a limited time.
> 
> To reproduce, at
> 
>   --\ editors        Text editors and word processors (2)
>     --\ main           The main Debian archive (2)
> i A emacs-bin-common           1:30.1+1-4               1:30.1+1-4+b1
> i   emacs-gtk                  1:30.1+1-4               1:30.1+1-4+b1
> 
> type '+' over "main", then type '.' until an upgrade is proposed
> without removals:
> 
> [6(6)/...] Actions: 1 install, 2 upgrades
> 
> then type '!' and 'g'. The following is proposed:
> 
> --\ Packages to be upgraded (2)
> iuA emacs-bin-common +1024 B   1:30.1+1-4               1:30.1+1-4+b1
> iu  emacs-gtk        -4096 B   1:30.1+1-4               1:30.1+1-4+b1
> --\ Packages being automatically installed to satisfy dependencies (1)
> piA libtree-sitter0. +219 kB   <none>                   0.22.6-5
> 
> Then type [Enter] over libtree-sitter0.:
> 
>          Packages                   Preview            libtree-sitter0.22 info
> aptitude 0.8.13 @ disset                 Disk: +216 kB           DL: 0 B/7998 kB
> piA --\ libtree-sitt +219 kB   <none>                   0.22.6-5
> [...]
>   Origin: Debian:experimental [amd64]
> 
> That's from experimental!
> 
> Same issue if I type '+' over "emacs-gtk" instead of "main".
> 
> apt does not have this issue:
> 
> disset:~> apt install -s emacs-gtk
> [...]
> Upgrading:                      
>   emacs-bin-common  emacs-gtk
> 
> Installing dependencies:
>   libtree-sitter0.22
> 
> REMOVING:
>   libtree-sitter0
> 
> Summary:
>   Upgrading: 2, Installing: 1, Removing: 1, Not Upgrading: 64
> Inst emacs-gtk [1:30.1+1-4] (1:30.1+1-4+b1 Debian:unstable [amd64]) []
> Inst emacs-bin-common [1:30.1+1-4] (1:30.1+1-4+b1 Debian:unstable [amd64]) []
> Remv libtree-sitter0 [0.22.6-4] []
> Inst libtree-sitter0.22 (0.22.6-6 Debian:unstable [amd64])
> Conf emacs-gtk (1:30.1+1-4+b1 Debian:unstable [amd64])
> Conf emacs-bin-common (1:30.1+1-4+b1 Debian:unstable [amd64])
> Conf libtree-sitter0.22 (0.22.6-6 Debian:unstable [amd64])
> 
> i.e. it proposes libtree-sitter0.22 0.22.6-6 from unstable rather
> than libtree-sitter0.22 0.22.6-5 from experimental.
> 
> Note that since libtree-sitter0.22 0.22.6-6 has
> 
>   Replaces: libtree-sitter0 (<< 0.22.6-5~)
> 
> the removal of libtree-sitter0 is safe.
> 
> Note also that aptitude does not give any warning at any time about
> the upgrade to experimental (even when typing 'g' later).

I'm afraid there's nobody left who understands the aptitude solver,
could reason whether the behavior is correct given the constraints
or suggest a different setting for SolutionCost that is not prone
to this problem.

I believe you explained the reasoning in your follow up where you
show it takes a lot of tries to get to your expected solution -
the solver might have given up too early and then not seen your
proposed solution yet. It does not claim to yield optimal results,
it by very definition is not able too - the solver is a heuristical
best-search solver, rather than a complete MaxSAT solver, and
it's infeasible to calculate all possible solutions, so it has
to make some cut offs in the search space it considers.

Now one thing to point out is that libtree-sitter0 is still
available in unstable. I don't know about aptitude; but apt
would consider this in its considerations and prefer to
keep libtree-sitter0 around rather than remove it (it may
magically get there by other means).

Building a solver that deals correctly with conflicting information
like this in development releases is pretty hard.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en