Bug#1035009: libocct-data-exchange-dev: missing Breaks+Replaces for liboce-modeling-dev when upgrading from bullseye
Helmut Grohne
helmut at subdivi.de
Sat May 13 11:22:04 BST 2023
Control: retitle -1 libocct-data-exchange-dev missing Conflicts: liboce-modeling-dev, liboce-visualization-dev
Hi Tobi,
Please Cc me if you want a reply.
On Mon, May 01, 2023 at 11:30:31AM +0200, Tobias Frost wrote:
> I cannot reproduce this. liboce-foundation-dev liboce-modeling-dev is deinstalled here when
> trying to installing libocct-data-exchange-dev.
> libocct-data-exchange-dev depends on libocct-foundation-dev, which conflicts liboce-foundation-dev.
> liboce-modeling-dev is depending on liboce-foundation-dev, so the conflict is inherited.
>
> Any hints what I am missing?
This is a tough one and you may say it is hair splitting. Due to the
dependencies involved, you cannot actually coinstall these packages.
When apt encounters this situation it will usually remove packages
before installing others, so when using apt, you usally cannot observe
this situation. That said, the resolver's decisions are subtle, so the
fact that you cannot presently observe it is an implementation detail
not to be relied on. You can observe it when using dpkg directly
however.
Keep in mind that Depends don't have to be satisfied in order to unpack
a package, so libocct-data-exchange-dev can be unpacked without its
dependency on libocct-foundation-dev being satisfied. Doing so is legal.
When libocct-foundation-dev is not installed, its conflicts are not in
effect either, so you really can get this unpack error (though not
easily).
I think this is worth fixing in bookworm anyhow.
* Adding these Conflicts is a very simple measure with low risk.
* The underlying Conflicts are an implementation detail that might
change down the road, so changes to other packages may render this
package rc buggy later.
* Spelling out all of these "hidden" conflicts with Conflicts
declarations makes static analysis of the archive way simpler as we
can just treat this situation as an error in all cases. In reality,
it's just this instance left since Thorsten fixed python3-meep, which
had a similar instance.
As such, I'd appreciate if you could bump up the severity again and push
this simple change to bookworm.
Helmut
More information about the debian-science-maintainers
mailing list