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

[Helmut Grohne]

Hi Peter,

On Fri, Apr 28, 2023 at 01:24:16AM +0100, Peter Green wrote:
> 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.

Thanks for looking into this so quickly. I concur: The Breaks are ok,
but the Replaces are not. Debian policy section 7.6.1 explicitly says
that Replaces don't work on virtual packages.

> 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.

Can you go into more detail as to what you mean with "don't support
version ranges"? In principle, you could declare the Replacs to be
slightly broader than necessary (i.e. instead of declaring against the
specific range, you can replace all old packages). Do you agree that
this is feasible?

> 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.

It's a big hammer. It'll work. It's a hammer we're looking into as part
of the DEP 17 thread on debian-devel at lists.debian.org currently, but I
recommend avoiding it if possible. Possible it seems in this case.

> 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.

I am sorry about that. This is a side-effect of earlier discussions
having stalled and only recently been picked up. However, these tests
should likely be running more continuously.

> 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.

 4. Continue to use Breaks the way they are. Declare Replaces against
    the physical package using a << relation. This would not allow the
    semver-suffixed package to be installed alongside, but Breaks and
    Replaces would no longer match up and that could make lintian
    unhappy.

 5. In a different bug, Samuel Thibault observed that the target package
    was not part of bullseye. As such, an upgrade scenario involving it
    was unlikely. All of the 6 affected librus-*-dev packages are not
    part of bullseye. We could argue that the risk of these effects
    showing up in practice is not big enough to warrant an invasive fix.
    Rather, we'd downgrade them to important (and upgrade to serious
    when we see them in the wild) and close them after bookworm (since
    we don't support skip upgrades).

> 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.

Let me know if you see 4 as a viable option.

> 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.

I filed these as serious, because these are policy violations with a
trivial fix. You made it quite clear that the premise of the fix being
trivial is false here. If the cure is worse than the symptoms, maybe we
should consider not applying the cure and select option 5.

Helmut