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.