[Pkg-rust-maintainers] Bug#880690: Bug#880690: Bug#880690: Bug#880690: dh-cargo: should build and test library

[Ximin Luo]

Control: retitle -1 dh-cargo: should test library

dh-cargo has been running `cargo build` as a test-build during override_dh_auto_test since version 3.

There are issues with running the test suite because that involves installing the dev-dependencies, and here it's very easy to get a cyclic-build-dependency. So for now I'll close this bug until someone is willing to put in the work to make this happen:

1. having dh-cargo run `cargo test` instead of `cargo build`, easy
2. make debcargo put dev-dependencies in Build-Depends, a bit harder
3. update `tests/sh/cargo-tree-deb-rec` to also output these extra dev-dependencies, a bit harder
4. run `tests/sh/integrate.sh -kbrz <our favourite crates>` to see how many of these result in cyclic Build-Depends, will take lots of time
5. propose an easily-maintainable workaround for the cycles in (4).

I'm not willing to do the work myself at this date, but I'll leave this bug open in case anyone wants to pursue it.

X

Ximin Luo:
> Josh Triplett:
>> tags 880690 + confirmed
>> severity 880690 wishlist
>> thanks
>>
>> On Fri, Nov 03, 2017 at 10:05:31PM +0100, Jonas Smedegaard wrote:
>>> Package: dh-cargo
>>> Version: 2
>>> Severity: important
>>>
>>> dh-cargo registers as a _build_ system, yet does not build the library
>>> nor does it execute its testsuite.
>>>
>>> I understand that Rust packaging policy mandates libraries should be
>>> _installed_ only as source, but that does not preclude ensuring that it
>>> properly builds and passes its testsuite.
>>
>> This is something we should work towards, and may be able to do on a
>> case-by-case basis, but we cannot run crate testsuites by default.
>> *Many* crates are not capable of running their testsuites given only the
>> contents of the .crate file; some require the full contents of the
>> upstream git repository (including non-trivial test data), or
>> non-standard tools, or git submodules, or any number of other things.
>>
>> Beyond that, even if the testsuite could be run with only those files,
>> neither "cargo test" nor "cargo build" can be reliably be run from the
>> unpacked .crate, because the unpacked crate may incorporate things like
>> workspaces. Only "cargo install cratename" (with a directory registry)
>> is expected to work from a .crate, and only from a binary package, not a
>> library package.
>>
>> I'm tagging this as confirmed because we *do* want to do it at some
>> point, and marking it as wishlist for the feature of allowing a package
>> to opt in to running the testsuite in cases where it is known to work.
>>
> 
> It's issues like this that make me wonder if it would be better to re-architect debcargo and the Rust packaging policy to be workspace-oriented rather than crate-oriented. I was unfortunately not aware of this distinction back when I was first reviewing this stuff, but now I am.
> 
> The benefit is that a "workspace" usually corresponds to a git repo, and this would map more easily to a Debian source package, and you could make sure that all the files needed to run tests are present.
> 
> OTOH there are a couple of issues I can see immediately:
> 
> 1. crates have their own version number histories, separate from the workspace's version number history. So we'd have to do some convoluted thing involving versioned Provides, for the binary packages, as well as some redundant naming scheme so dependencies can be properly expressed.
> 
> 2. cargo does not seem to forbid the situation where workspace-A/crate-1 depends on workspace-B/crate-1 depends on workspace-A/crate-2 which would give a circular dependency if we did workspace-based source packages. We have a similar situation with opam the ocaml package manager, and had seen some arrangements like this "in the wild" but so far was able to convince upstreams to break these quasi-cycles, after some bumps in the initial explanation attempts. I am not sure if most rust projects would accept our argument that these sorts of arrangements are Bad however, it took many paragraphs over several mails for me and others to explain this to the aforementioned ocaml projects.
> 
> and possibly other issues too.
> 
> X
> 


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