[Pkg-rust-maintainers] Packaging software written in Rust

[Josh Triplett]

A minor correction, and some preliminary investigation:

On Sun, Jul 17, 2016 at 08:57:40PM -0700, Josh Triplett wrote:
> I think we can reflect cargo dependencies directly into Debian dependencies, and then let apt do the job of finding the newest version that works; any of cargo's version specifications can map to an expression in Build-Depends. We can have every library -dev package install source into a versioned path, so packages can coexist, and use provides of virtual packages to allow the introduction of parallel versions without requiring source changes in dependent packages for transitions. In the common case, we can have the foo source package version 1.2.3 build librust-foo-dev; however, if two incompatible versions of foo become popular, we can have two versioned source packages build versioned -dev packages that each provide librust-foo-dev. Both library and binary packages can have Build-Depends like "librust-foo-dev (>= 1.2.1), librust-foo-dev (<< 2)", which corresponds to Cargo.toml foo="1.2.1". Every version expression on http://doc.crates.io/specifying-dependencies.html should work as a Debian Build-Depends expression.
> 
> I haven't seen too many instances of excessively precise dependencies. Most of the time, that seems to occur with packages that have gone through some major transition, similar to an SONAME change. (The url crate went through such a transition recently, hiding many of its internals from the public API.) So I hope we can avoid having multiple parallel crate versions in the majority of cases, just as we avoid having multiple parallel C library packages in the majority of cases.
> 
> I can understand wanting to support local distro patches. We should be very careful doing so, as it seems questionable to patch a crate while keeping the same version number; that breaks some of Cargo's assumptions about reproducibility. I'd rather have a separate crate and a replace stanza. However, if we absolutely had to, directory registries seem to support that.
> 
> A .crate file is a .tar.gz, so we can probably treat that as a .orig.tar.gz, and add a cargo command to generate a Debian diff. Lib crates won't need anything more than that, and only binary packages will invoke cargo from debian/rules.
> 
> That leaves three complications I can see:

s/three/two/

> - Sources that want to build multiple crates, with path dependencies. I'll need to look at the resulting .crate files to see if we can just treat them as separate packages.

We can; I tested this, and I could "cargo package" each crate
independently, which produced separate .crate files with a disjoint set
of included sources.  I think we can either ship the resulting crates
independently, or ship a package with multiple .crate.orig.tar.gz files
that builds all the crates.  The former seems simpler, though the latter
might help if a package expresses an exact version constraint on the
crates it bundles.  Let's go with the former for now, until we run into
a package that makes that problematic.

> - -sys crates that link C code. Some of these support building against the system library, some don't. Fortunately, libgit2-sys does. But we'll have to figure out a way to systematically specify system libraries for all crates.

It looks like libgit2-sys supports an environment variable to use
pkg-config to find libgit2; if set, it completely ignores its built-in
copy of libgit2, which means we can avoid shipping that copy entirely.

However, that means we'll need that environment variable set when
building packages of bin crates that incorporate libgit2-sys (by way of
git2-rs).  That seems like a pain.

One possible proposal: librust-libgit2-sys-dev can have a Depends on
libgit2-dev, and can ship a file
/usr/share/rust/env.d/libgit2-sys-$version.conf (near the installed
Cargo directory registry in /usr/share/rust/cargo/), which contains
"LIBGIT2_SYS_USE_PKG_CONFIG=1".

"dh_cargo_bin" (or whatever we end up calling it) can then parse
/usr/share/rust/env.d/*.conf and export all of those environment
variables before invoking cargo.

That's a fairly annoying hack, but it'll work for now.  To reduce the
need for it in the future, we could start propagating some standard
environment variable like CARGO_USE_SYSTEM_DEPS=1 and ask upstream
crates to observe that.  I can write an RFC for that.

> I'll see if I can get a version of cargo with the directory registry patches to build some crates with only local sources.

Still working on this.

> - Josh Triplett
> 
> On July 17, 2016 6:40:00 PM PDT, Angus Lees <gus at debian.org> wrote:
> >Cool!
> >
> >I need to go read the patch/PR again, but I'm still unclear whether any
> >of
> >https://github.com/rust-lang/cargo/pull/2857 allows for *modified*
> >local
> >registries (ie: those where the contents are not a strict,
> >hash-identical
> >subset of crates.io).
> >
> >The main hurdles (as I see them) are:
> >- some sort of cargo support for local *possibly patched* registries
> >- some sort of toolchain for easily generating/maintaining Debian
> >packages
> >for crates.  Doesn't have to be fancy, just better than making 50
> >packages
> >by hand.
> >- we probably need a conversation/policy around library versions.  It's
> >easy for a cargo package to need multiple versions of a single crate,
> >and
> >we need to work out how much we want to accommodate that versus
> >patching
> >applications/libraries to use a narrower set of versions.
> >- an application package that provides motivation (git-series!)
> >
> >Fwiw, in my earlier testing I found it easy to make cargo fail if it
> >tries
> >to access the network by just setting a bogus http_proxy env var.
> >
> >I did some work earlier towards a "cargo debmake" subcommand (
> >https://github.com/anguslees/cargo-debmake) but I got lost in trying to
> >add
> >something like Alex's directory registries PR to cargo (before that PR
> >came
> >out) and made little further progress.  It may be easier to just start
> >again.
> >
> >Re helping: Yes, any of it would be helpful!  I guess first we hack
> >things
> >up until git-series will compile from crates provided via a central
> >on-disk
> >registry - and then we worry about making that pretty.
> >
> > - Gus
> >
> >On Mon, 18 Jul 2016 at 10:45 Josh Triplett <josh at joshtriplett.org>
> >wrote:
> >
> >> I've just released git-series
> >> (https://github.com/git-series/git-series), a git tool written in
> >Rust.
> >> git-series tracks the "history of history", tracking changes to a
> >patch
> >> series over time through rebases and other non-fast-forwarding
> >changes.
> >> I wrote git-series to help with the maintenance of distribution
> >> packages, backports, patch series for submission (PATCHv2, PATCHv3,
> >> ...), and other development processes that may want to rewrite
> >history.
> >> In particular, git-series avoids having to pull patches out of git
> >and
> >> into something like quilt in order to version them.
> >>
> >> I'm interested in packaging git-series (and its dependencies) for
> >> Debian.
> >>
> >> We previously discussed the process of packaging Rust software for
> >> Debian.  Since then, Alex Crichton wrote a new version of cargo
> >support
> >> for "local registries" and "directory registries" (see
> >> https://github.com/rust-lang/cargo/pull/2857), which I think should
> >> support the approach of packaging libraries as source.  In addition,
> >> https://github.com/rust-lang/cargo/pull/2811 adds a flag to cause
> >Cargo
> >> to fail if it would access the network.
> >>
> >> Other than those Cargo pull requests, what would need to happen to
> >make
> >> it possible to package software written in Rust for Debian?  And how
> >can
> >> I help?
> >>
> >> - Josh Triplett
> >>
>