Hi,
On 2/28/24 23:49, Vincent Lefevre wrote:
# 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)]
That is a valid possible resolution. Presumably, if you reject this
resolution, it will instead propose to upgrade apt-utils, install
libapt-pkg6.0t64 and remove libapt-pkg6.0.
Since that is a larger change, the conservative proposal comes first.
apt-utils has a versioned dependency on apt, which means upgrading apt
alone (which you requested) breaks another "unrelated" package. There
has been some debate that resolvers should favour upgrading all binaries
that are built from the same source together, but that has not been
implemented yet, and it is unclear if that would have changed anything here.
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.
Note that you haven't requested an "upgrade" (which would likely have
worked, because it would have switched both apt and apt-utils to the new
version, and the remaining involved packages were automatically
installed as dependencies of the packages being upgraded).
Simon
_______________________________________________
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
