On 2020-03-19 09:50 -0500, Mark Allums wrote:
> On 3/19/2020 8:03 AM, Marco Möller wrote:
>> The dependency libkpmcore9 cannot be upgraded from libkpmcore8,
>> therefore the package partitionmanager is hold back from upgrades.
>> What exactly causes "apt upgrade" to not be able to upgrade to
>> libkpmcore9 from libkpmcore8? Below I will show what I figured out
>> so far. Is there some more detail I could search for? Or is it a bug
>> and if so, for which package (libkpmcore9 or apt or some other
>> instance) should I report it?
>> My OS is Debian testing ("Bullseye"), kernel-release 5.4.0-4-amd64
>> and kernel-version being #1 SMP Debian 5.4.19-1 (2020-02-13),
>> besides the below mentioned packages upgraded to the newest package
>> versions.
>>
>>
>> I have done the following to clarify the situation, which shows that
>> the hold back is caused by the dependency libkpmcore9:
>> apt upgrade partitionmanager -s
>> The following packages have unmet dependencies:
>> partitionmanager : Depends: libkpmcore9 (>= 4.1.0) but it is not
>> going to be installed
>> E: Broken packages
>
> Chances are, there is more coming from the maintainers. Simply
> waiting a week or so may clear this up. The dependencies don't work
> because another package needs to be upgraded or installed that hasn't
> yet been uploaded to the mirrors. This happens frequently in testing
> and Sid (and experimental).
Small correction: it happens frequently in sid indeed, but it is _not_
supposed to happen frequently in testing. In this case, it happens
because libkpmcore9 is not coinstallable with libkpmcore8. I would
consider that a bug, but I don't know anything about the kpmcore
package.
Aptitude by default removes unused packages (automatically installed
packages with no reverse dependencies) with the "safe-upgrade" command,
which I find very useful. I think apt should behave the same if you set
APT::Binary::AutomaticRemove to true in the configuration, but I have
not tested that.
Cheers,
Sven
