Interesting problem. Debian source deps are usually quite opinionated ("as the Debian maintainer, I'm choosing to build this with these options enabled and against these versions of other libs").<div><br></div><div>I think we need to just declare a minor version (ie: specific source package) that we're building against. At the easiest that could be "newest", but I expect at least somewhere we'll need to use some other version in order to satisfy all the related package constraints. We could just handle that latter with human overrides - if we don't have better tooling.</div><div><br></div><div>Not also that we _can_ keep the full expressiveness if we want - we just have to be more careful choosing the *first* alternate dependency. There's some risk with that though, in that we aren't testing all the other implied version combinations.</div><div><br></div><div> - Gus<br><br><div class="gmail_quote"><div dir="ltr">On Sun, 18 Feb 2018, 21:01 Vasudev Kamath <<a href="mailto:vasudev@copyninja.info">vasudev@copyninja.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Ximin,<br>
<br>
After I introduced the alternative for version range semantics like<br>
">=0.3.14, << 0.5.0" to resolve in the form<br>
librust-rand-0.3+default-dev (>= 0.3.14) | librust-rand-0.4+default-dev<br>
<br>
I observed a build failure which was actually suggesting it can't find<br>
dh-cargo:amd64 >= 3. A closer investigation revealed following.<br>
<br>
1. cargo-tree which is used by our testing script resolves rand version<br>
range above to a single version 0.4.12 which satisfies upstream<br>
predicate.<br>
2. Since we rely on cargo-tree to get the version information we build<br>
librust-rand-0.4+default-dev and librust-rand-0.3+default-dev is not<br>
built.<br>
3. Since sbuild only checks for first option in case of alternatives in<br>
build dependency the build fails.<br>
<br>
For the time being I've added --resolve-alternatives to sbuild command<br>
in tests/sh/integrate.sh so that we can complete the build and see the<br>
output. Now while writing this mail I'm trying to build debcargo and<br>
hoping it will succeed. This fixed the case of build failure for num-bigint.<br>
<br>
Now coming to the point on how do we really handle build dependency, I<br>
think if we consider to build all crates during packaging we should have<br>
some way to avoid having alternative build depends. What I currently<br>
think of is have logic separately for generating build-depends which<br>
will use cargo API to resolve above like version ranges to a single<br>
suitable version and generate build depends on that single version. What<br>
do you think of this approach?. If you have a better approach I would be<br>
happy to know about it.<br>
<br>
Best Regards,<br>
<br>
--<br>
Vasudev<br>
<br>
_______________________________________________<br>
Pkg-rust-maintainers mailing list<br>
<a href="mailto:Pkg-rust-maintainers@lists.alioth.debian.org" target="_blank">Pkg-rust-maintainers@lists.alioth.debian.org</a><br>
<a href="https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers" rel="noreferrer" target="_blank">https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers</a><br>
</blockquote></div></div>