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

[Fabian Grünbichler]

On Thu, Jul 06, 2023 at 04:39:08PM +0100, Peter Green wrote:
> > 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.

and, with a bit of unexpected delay (sorry), the result of a discussion
Helmut and me had in parallel on IRC:

the issue with Conflicts arises in combination with M-A:same, since dpkg
and apt don't agree on which one of those two "angles" has higher
priority. to sort that out would require a release cycle or two.

it seems like this leaves the other alternative from #1034939 [0,
CC-ed], namely, switching the breaks and replaces to point at the real
package (version guarded), so that upgrading from "old" non suffixed
package (for which a newer version should exist by definition if a
suffixed package of the same version exists) while installing the
suffixed package of the same "old" version at the same time works. the
main downside (and reason why we preferred the Conflicts-based variant)
is that this means that two suffixed packages with different versions
are no longer co-installable (since the one with the higher version
would break the older one). thankfully, such issues should seldomly
matter in practice. or we could investigate just switching the replaces,
and keeping the breaks as is.

0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034939