[Pkg-rust-maintainers] Bug#967954: debcargo: generated ranged build-deps result in "BD-uninstallable" on debian buildd network

[Daniel Kahn Gillmor]

Just to clarify why this is a concern:

 - this behavior on the buildds is deliberate.  It's an explicit
   feature of sbuild.

 - it is intended to ensure more-deterministic builds

 - it is also mentioned in debian-policy, in the first footnote of §7.1:

>    While Build-Depends, Build-Depends-Indep and Build-Depends-Arch
>    permit the use of alternative dependencies, these are not normally
>    used by the Debian autobuilders. To avoid inconsistency between
>    repeated builds of a package, the autobuilders will default to
>    selecting the first alternative, after reducing any
>    architecture-specific restrictions for the build architecture in
>    question. While this may limit the usefulness of alternatives in a
>    single release, they can still be used to provide flexibility in
>    building the same package across multiple distributions or releases,
>    where a particular dependency is met by differently named packages.

So in practice, any Cargo.toml dependency range that has an upper bound
will be converted by debcargo to a disjunction in the Build-Depends.
This disjunction will be interpreted by sbuild as "the most recent
version before the upper bound".

This results in unnecessary FTBFS when the build-dep is in debian, but
the most recent version before the upper bound is not yet in debian.

I will probably be working around this by patching Cargo.toml files so
that the generated disjunction targets the version of the dependency
that is in debian unstable, but it's an ugly thing to need to do.

I'm at a loss for how to address this, or what debcargo *should* do to
make the situation better. ☹

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20201015/e33f505e/attachment-0001.sig>