[Pkg-rust-maintainers] debcargo update handling alternative build depends

[Ximin Luo]

Vasudev Kamath:
> Hi Ximin,
> 
> After I introduced the alternative for version range semantics like
> ">=0.3.14, << 0.5.0" to resolve in the form
> librust-rand-0.3+default-dev (>= 0.3.14) | librust-rand-0.4+default-dev
> 
> I observed a build failure which was actually suggesting it can't find
> dh-cargo:amd64 >= 3. A closer investigation revealed following.
> 
> 1.  cargo-tree which is used by our testing script resolves rand version
>     range above to a single version 0.4.12 which satisfies upstream
>     predicate.
> 2. Since we rely on cargo-tree to get the version information we build
>     librust-rand-0.4+default-dev and librust-rand-0.3+default-dev is not
>     built.
> 3. Since sbuild only checks for first option in case of alternatives in
>     build dependency the build fails.
> 
> For the time being I've added --resolve-alternatives to sbuild command
> in tests/sh/integrate.sh so that we can complete the build and see the
> output. Now while writing this mail I'm trying to build debcargo and
> hoping it will succeed. This fixed the case of build failure for num-bigint.
> 
> Now coming to the point on how do we really handle build dependency, I
> think if we consider to build all crates during packaging we should have
> some way to avoid having alternative build depends. What I currently
> think of is have logic separately for generating build-depends which
> will use cargo API to resolve above like version ranges to a single
> suitable version and generate build depends on that single version. What
> do you think of this approach?. If you have a better approach I would be
> happy to know about it.
> 
> Best Regards,
> 

Thanks for getting to the root of this issue! That sounded like a tricky one to debug.

A very simple solution would be to reverse the list so the highest version appears first, but this wouldn't work well for ranges whose upper limit doesn't yet exist as a real crate, nor for >-only ranges that don't have an upper limit, so I think we have to reject this simple solution.

I think it would be preferable to keep the list of alternatives, but do the resolving as you say and use that version as the first one in the list of alternatives. It would be good to be able to override this "first version" in the config file as well.

Did your build succeed?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git