[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

[Sven Joachim]

Control: severity -1 normal

On 2024-02-28 15:49 +0100, Vincent Lefevre wrote:

> Source: apt
> Version: 2.7.12+nmu1
> Severity: serious
>
> While there are no upgrade issues with apt itself (according
> to "apt install -s apt"), aptitude does not want to upgrade
> apt automatically, while this just appears to be a package
> rename:
>
> # aptitude install apt
> The following packages will be upgraded:
>   apt{b} apt-doc
> 2 packages upgraded, 0 newly installed, 0 to remove and 180 not upgraded.
> Need to get 1622 kB of archives. After unpacking 0 B will be used.
> The following packages have unmet dependencies:
>  apt : Depends: libapt-pkg6.0t64 (>= 2.7.12+nmu1) but it is not going to be installed
>  apt-utils : Depends: apt (= 2.7.12) but 2.7.12+nmu1 is to be installed
> The following actions will resolve these dependencies:
>
>      Keep the following packages at their current version:
> 1)     apt [2.7.12 (now, testing)]
>
> I don't know whether this is actually an issue with aptitude, but at
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059068#15
>
> David Kalnischkies says:
> | You should really know this by now as that isn't your first report, but
> | okay: Upgrade problems are NEVER a problem to be solved in apt,
> | they are ALWAYS a problem in the involved packages. NO EXCEPTIONS.
>
> So, I suppose that this is also the case for aptitude: if aptitude
> cannot upgrade just because of a rename, then this is a problem in
> the involved packages.

No, in this case it is a problem with aptitude's resolver which
manifests itself due to the following configuration setting:

> Aptitude::ProblemResolver::SolutionCost "safety, removals";

This does cause aptitude to hold apt back by default, rather than remove
libapt-pkg6.0.  You can press 'n' at the prompt, the next solution
aptitude then suggests is to upgrade apt.

Cheers,
       Sven