[Pkg-rust-maintainers] Bug#1034939: librust-<crate>-<semver>-dev: missing Breaks+Replaces for librust-mio-dev when upgrading from bullseye

[Peter Green]

Summarising a number of bug reports by Helmut Ghrone:

> Please ensure that librust-<crate>-<semver>-dev has sufficient Breaks and Replaces declarations.

The issue specifically appears to be that the breaks+replaces are declared
against a virtual package, it seems dpkg is honoring the breaks against the
virtual package but not the replaces. So it correctly marks the package from
stable as broken, but fails to actually unpack the package from testing.

Declaring against the physical package is also problematic becase Debian package
relationships don't support version ranges. What this would likely mean in
practice is it would be possible to co-install the "current" semver alongside
one previous semver, but it would not be possible to co-install two different
previous semvers.

Another option may be to use "Conflicts" instead of "Breaks". This should force
the old package to be upgraded or removed before the semver-specific package
can be unpacked.

I feel the timing of these bugs is very unfortunate. I don't object to
people running QA checks, but it's generally easier to deal with bugs if
they are reported earlier in the freeze process. The timing of these bugs
leaves little time for discussion if we are to get the fixes in before the
full freeze.

As I see it we have a few options to deal with this for bookworm.

1. Make debcargo Use Conflicts instead of Breaks.
2. Make debcargo declare Breaks/Replaces against the physical package
    version using a << dependency. This will allow the non-semver suffixed
    package to be installed alongside one semver-suffixed package, but with
    our current virtual packages scheme would not allow two semver-suffixed
    packages of the same crate to be coinstalled.
3. Add manual breaks/replaces for the versions in bullseye, this will
    paper over the issue for bullseye-bookworm upgrades, but is not a long
    term fix.

Do any other members of the rust team have an opinion on this? I'm
personally inclined towards option 1 and intend to implement it if
noone objects in the next couple of days.

Do the release team have an opinion on this? It looks like only one of
the packages involved (rust-env-logger-0.7) is a key package.