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
