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

[Angus Lees]

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").

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.

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.

 - Gus

On Sun, 18 Feb 2018, 21:01 Vasudev Kamath <vasudev at copyninja.info> wrote:

>
> 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,
>
> --
> Vasudev
>
> _______________________________________________
> Pkg-rust-maintainers mailing list
> Pkg-rust-maintainers at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20180218/37e50b67/attachment.html>