[Pkg-rust-maintainers] debcargo and dh-cargo ready for production use; sponsor request

[Luca BRUNO]

On Sunday, 4 December 2016 23:47:08 UTC Josh Triplett wrote:
> I just tagged and pushed version 1 of dh-cargo
> <https://anonscm.debian.org/git/pkg-rust/dh-cargo.git> and version 1.0.0
> of debcargo <https://anonscm.debian.org/git/pkg-rust/debcargo.git>, and
> published the latter to <https://crates.io/crates/debcargo>.  I've
> addressed everything needed to use them in production, and I've locally
> tested using them to package numerous crates.  Could a Debian Developer
> in pkg-rust-maintainers please review and upload dh-cargo 1?

Thanks for your great work! I would however suggest to:
 * start drafting the policy this implements, at
    https://wiki.debian.org/Teams/RustPackaging/Policy
 * hold dh-cargo and debcargo till the policy is finalized
 * Target those at experimental, or anyway hold them out of stretch

Also, care to join #debian-rust on OFTC?

> debcargo includes all the dependencies for the "default"
> feature in the main librust-cratename-dev package; for non-default
> features, debcargo generates a librust-cratename+featurename-dev
> package, which pulls in any additional dependencies needed for that
> feature.

This looks convoluted and will pollute the package namespace (and also
relies on the fact that "featurename" charset is a subset of the package name 
charset), but I don't have any better ideas at the moment.
I still have some concerns though.

> Because many application crates have dependency trees that involve more
> than one version of the same library (for instance, during the current
> upstream transition from thread_local 0.2.7 and thread-id 2.0.0 to
> thread_local 0.3.0 and thread-id 3.0.0), I added a --multi option to
> include the ABI version in the source and binary package names,
> producing co-installable packages.  debcargo still defaults to
> generating unversioned package names, but you can pass --multi when
> packaging a library crate that you need to support more than one version
> of. 

This looks like an inverted default, and possible something that could be 
better handled by versioned provides. Care to draft out in the policy how
semver compatibility will map to deb dependencies resolution?

> debcargo will still generate a binary package by
> default for crates that don't also build a library, and for some library
> packages we'll want to pass --bin, such as for future packaging of cargo
> (which includes both a library and the "cargo" binary).

How do you handle path dependency on same-repository crates?
For example, cargo depends on fake versions of crates-io, see
https://github.com/rust-lang/cargo/issues/2989#issuecomment-240040153

> As discussed in my previous mail, I've reworked dh-cargo to never invoke
> cargo directly on unpacked .crate sources; instead, it always sets up a
> directory repository and invokes "cargo install cratename".  This allows
> it to reliably build all crates, even those whose Cargo.toml files use
> workspaces, path dependencies, and other interesting features that apply
> when Cargo runs directly on a source tree (rather than pulling in
> sources from a registry).

This is a much saner way of doing things compared to what all the hoops I 
jumped through to bootstrap cargo :)
 
> Note that none of this automation solves the issue of upstream crates
> that embed library sources directly in the crate sources.  For those, we
> may want to strip out the embedded sources to ensure they don't get
> used, but in any case we'll definitely want to build against the
> corresponding system libraries instead.

I guess some discussion with upstream around best-practices for vendored 
native libs should happen. It will make our life easier to detect (and filter) 
those.

> That will require adding
> appropriate Depends on a C library -dev package to the Rust -sys package
> for that library.  (We may want to add a debcargo option for that in the
> future.)  This also requires some care to make sure we depend on an
> appropriate version corresponding to the embedded sources (which in some
> cases represent a git snapshot of the library).
> 
> Many packages will autodetect a system version of the library
> if available.  A few packages, such as libgit2-sys, require an
> environment variable set to detect a system version;

https://github.com/alexcrichton/git2-rs/pull/80

> we can either set that environment variable in the debian/rules of
> applications depending on those packages (which seems wrong), set that
> environment variable in dh-cargo (better), or create a
> /usr/share/cargo/env.d or similar to provide such snippets (most
> general, but most complex).

The env flag needs to be transitively passed down to dependencies, so
a debian/rules export won't probably work.

Ciao, Luca

-- 
«Доверяй, но проверяй»
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20161205/47f5e7fa/attachment.sig>