[Pkg-rust-maintainers] Problems with semver-suffix and non-suffix crates of the same version

Wolfgang Silbermayr wolfgang at silbermayr.at
Mon Sep 9 05:24:59 BST 2019


Whenever we upload a semver-suffixed version of a crate, and we have the
same version already packaged in the archive without a semver suffix,
packages that depend on this version can become uninstallable. We have
recently seen this when building up a new `librust-rand-0.6` dependency
tree while not being able to update `librust-rand` from version "0.6.*"
to "0.7.*".

This seems to happen by two packages having a 'Provides:' entry for a
package with exactly the same version number making it impossible for
dpkg resolvers to determine which package to install.

We usually try to update the non-suffixed version as soon as possible,
but because the suffixed versions need to pass the NEW queue, we would
have to update the non-suffixed version immediately after it got
accepted, and then it must be accepted immediately. That's of course not
always the case, e.g. if a crate introduces a new feature which
manifests in an additional binary package, it has to go through NEW as well.

I had the quick idea that maybe we should add a debian revision to the
version number of the suffixed package by default, so the 'Provides:'
field contains a different version than in the non-suffixed package.
This could either be separated with a '+' (to prefer the suffixed
version) or a '~' (to prefer the non-suffixed version) - that would be
subject to discussion.

I don't have enough experience with packaging to judge whether this
would work properly in all cases, and also whether this would introduce
other unwanted side-effects.

We would have to decide if this should be some automatic mechanism
(either in our `update` script or in the `debcargo` tool), or if we
would do it by hand - e.g. in a `debcargo.toml` setting.

Wolfgang.



More information about the Pkg-rust-maintainers mailing list