[Pkg-rust-maintainers] Bug#1040477: Bug#1040477: librust-syn-1-dev fails to coinstall

[Peter Green]

> I'd be very interested in knowing what this self-conflict is supposed to
> achieve.

It is common upstream for there to be multiple semver-incompatible versions
of each rust crate in use at a given time. Incompatibilities can range from
minor corner cases that are easily patched away to complete redesigns

We try to only package one version of each crate at a time, but sometimes
that isn't practical. When it becomes impractical we crate semver-suffix
packages. The convention in the rust team is that the un-suffixed packages
are used for the latest version and suffixed versions are used for any
older versions.

When packaged crates are installed on a Debian system. They are installed
in a path that depends on the upstream version of a crate.

This creates a problem though, if the same version is packaged as both
a non-suffixed and suffixed version. Something that happens fairly
frequently when a new version is introduced e.g.

Before:

librust-foo-dev version 1.23-1

After:

librust-foo-1-dev version 1.23-2
librust-foo-dev version 2.34-1

This doesn't always happen, indeed it didn't happen in the case of syn,
because a new upstream release of syn 1.x at the same time at the same
time the semver suffix was introduced. However debcargo works on one
crate at a time. so it doesn't know if this has happened or not.

When this happens, it leads to a file conflict. In an attempt to fix
this breaks+replaces were added. Unfortunately these proved to be
insufficient because while breaks against virtual packages work,
replaces apparently don't. We are in the process of considering
several options to fix this, but overall switching to conflicts+replaces
seems the least likely to be problematic.

Do you encounter the same problem if you replace the breaks with
conflicts? if so we would need to do something about it. I think
the easiest would probablly be to put a version constraint on the
conflicts/replaces. It would mean we would have to take care that
semver-suffixed packages had a higher Debian revision than their
un-suffixed counterparts, but I think that is managable.