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

[Josh Triplett]

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:
- 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.
- -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.

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

- 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
>>