<div dir="ltr">Alas, there's a planet between RustConf and me, and my employer wouldn't fund such a trip :(<div><br></div><div>(As it happens, I gave exactly that talk at the local Rust meetup a few months ago.  It wasn't recorded, but anyone is welcome to reuse the slides if they wished to give a similar talk: <a href="http://anguslees.github.io/talks/2015-12-01-rust-packaging/reveal.pdf">http://anguslees.github.io/talks/2015-12-01-rust-packaging/reveal.pdf</a>)</div><div><br></div><div> - Gus</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 24 May 2016 at 13:58 Josh Triplett <<a href="mailto:josh@joshtriplett.org">josh@joshtriplett.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I definitely found out the hard way that cargo doesn't like to work<br>
without a network, when I tried to hack on some Rust code on an<br>
airplane.<br>
<br>
Ignoring Cargo.lock files makes sense.  They have some information of<br>
value, but we can't usefully use any of it.<br>
<br>
I agree that we need co-installability of libraries to some extent.  At<br>
least in theory, Rust libraries should use semantic versions, so we<br>
should only need co-installable packages of different major versions; of<br>
course, theory and practice may vary there.<br>
<br>
I don't think the license file issue really matters; explicit metadata<br>
in Cargo.toml should suffice. Ditto for only providing the sources via<br>
<a href="http://crates.io" rel="noreferrer" target="_blank">crates.io</a>; that seems like an acceptable upstream source (as long as the<br>
issues with checksums and verification get sorted out).<br>
<br>
I really like your plan of just packaging libraries as source code for<br>
now.  If we can get it to work, it seems likely to produce sensible<br>
results far sooner than getting a binary package ecosystem to work; it<br>
also avoids needing hundreds of bin-NMUs after every rustc upload.  And<br>
the source approach also allows the final program to specify cargo<br>
feature flags for its dependencies; a pre-compiled binary library<br>
wouldn't support that.<br>
<br>
I do indeed have a non-hypothetical use case for Rust application<br>
packaging.  I plan to publish a program for production use in the next<br>
few weeks, built via Rust, that I'd like to get packaged (in a properly<br>
policy-compliant way) by various distributions.  I'll post a mail here<br>
when I get it released.<br>
<br>
Do you (or any of the other Debian Rust folks) plan to attend RustConf?<br>
Have you considered submitting a talk/BoF proposal on distribution<br>
packaging?<br>
<br>
- Josh Triplett<br>
<br>
On Tue, May 24, 2016 at 01:28:51AM +0000, Angus Lees wrote:<br>
> I think you've precisely summarised the plans - the only extra bit I'd add<br>
> is ensuring that we correctly add Built-Using fields to the output<br>
> (application) .debs.  Afaik none of this is written up anywhere better than<br>
> the occasional post to this mailing list.  And of course none of the<br>
> tooling actually exists.<br>
><br>
> There's been a few early attempts (by me and others) at making cargo do<br>
> what we need, and writing a dh_cargo.  My efforts never got far enough to<br>
> work, and haven't kept up with recent changes to cargo.   I did get far<br>
> enough <<a href="https://github.com/anguslees/cargo-debmake" rel="noreferrer" target="_blank">https://github.com/anguslees/cargo-debmake</a>> to conclude that adding<br>
> an actual cargo subcommand ("cargo-debbuild") in Rust was feasible and<br>
> reusing cargo libraries was probably of greater benefit than reusing<br>
> (python/perl) debhelper libraries.  Ymmv of course.<br>
><br>
> Some minor complications to be aware of:<br>
> - It's awkward to get cargo to not use the network.  You can provide it<br>
> with a complete copy of the <a href="http://crates.io" rel="noreferrer" target="_blank">crates.io</a> metadata in the exact same directory<br>
> tree layout; there are attempts like<br>
> <a href="https://github.com/rust-lang/cargo/pull/2361" rel="noreferrer" target="_blank">https://github.com/rust-lang/cargo/pull/2361</a> which also assume they're<br>
> mirroring an identical subset of <a href="http://crates.io" rel="noreferrer" target="_blank">crates.io</a>; but I don't think I've seen a<br>
> solution here that makes me immediately think "aha, good."<br>
> - As far as I can work out, the correct thing for us to do as a distro is<br>
> to ignore any upstream Cargo.lock, and provide our own integration<br>
> testing/assurance/repeatability.<br>
> - It's important that multiple versions of Rust build-deps are<br>
> co-installable, since larger projects tend to have transitive dependencies<br>
> on more than one version of common libraries (for better or worse).<br>
> - Many Rust crates have no sensible point to retrieve the source other than<br>
> through <a href="http://crates.io" rel="noreferrer" target="_blank">crates.io</a>.  In particular, many upstream git repos don't reliably<br>
> have a way to link git revisions to <a href="http://crates.io" rel="noreferrer" target="_blank">crates.io</a> releases.<br>
> - The only mention of a license for crates is often just the single field<br>
> in the <a href="http://crates.io" rel="noreferrer" target="_blank">crates.io</a> metadata.<br>
> - A number of Rust *-sys library packages include vendored copies of C<br>
> libraries.  The good news is that all of these that I looked at found+used<br>
> the local system library via pkg-config just fine, so we can strip the<br>
> upstream sources from our packaging and avoid having to audit licenses, etc.<br>
><br>
> To avoid you websearching, here's a selection of previous public<br>
> discussions on the topic: (I think they're all my posts, but that's just<br>
> because I could remember what to search for to find those ;)<br>
> - (Early post):<br>
> <a href="https://internals.rust-lang.org/t/how-to-distro-package-a-cargo-using-rust-executable/1785" rel="noreferrer" target="_blank">https://internals.rust-lang.org/t/how-to-distro-package-a-cargo-using-rust-executable/1785</a><br>
> - (Me explaining the plan again to upstreams):<br>
> <a href="https://internals.rust-lang.org/t/perfecting-rust-packaging/2623/57" rel="noreferrer" target="_blank">https://internals.rust-lang.org/t/perfecting-rust-packaging/2623/57</a><br>
> <<a href="https://internals.rust-lang.org/t/perfecting-rust-packaging/2623/57?u=gus" rel="noreferrer" target="_blank">https://internals.rust-lang.org/t/perfecting-rust-packaging/2623/57?u=gus</a>><br>
> - (A summary of some early hacks):<br>
> <a href="https://internals.rust-lang.org/t/perfecting-rust-packaging-the-plan/2767/26" rel="noreferrer" target="_blank">https://internals.rust-lang.org/t/perfecting-rust-packaging-the-plan/2767/26</a><br>
> <<a href="https://internals.rust-lang.org/t/perfecting-rust-packaging-the-plan/2767/26?u=gus" rel="noreferrer" target="_blank">https://internals.rust-lang.org/t/perfecting-rust-packaging-the-plan/2767/26?u=gus</a>><br>
><br>
> I'd like to resume some of this, if you have a non-hypothetical need for<br>
> any of it (other than cargo itself).  It was hard to maintain enthusiasm<br>
> when I felt cargo upstream had zero empathy with our use-case :/<br>
><br>
>  - Gus<br>
><br>
> On Tue, 24 May 2016 at 01:25 Josh Triplett <<a href="mailto:josh@joshtriplett.org" target="_blank">josh@joshtriplett.org</a>> wrote:<br>
><br>
> > [Please CC me on replies.]<br>
> ><br>
> > Do we have any guidelines on packaging software written in Rust, and in<br>
> > particular software built using Cargo?<br>
> ><br>
> > Software packaged for Debian can't let Cargo pull down packages from the<br>
> > network.  Given that, do we have an established procedure to package<br>
> > Rust library crates (from <a href="http://crates.io" rel="noreferrer" target="_blank">crates.io</a> or otherwise), and then to point<br>
> > Cargo exclusively at the packaged crates?  Preferably in a way that only<br>
> > involves passing options to Cargo, without making any changes to<br>
> > Cargo.toml?<br>
> ><br>
> > Rust doesn't have a stable library ABI ("yet", I hope), so I don't think<br>
> > it makes sense yet to package shared Rust libraries; however, I think we<br>
> > can create -dev packages for crates, and then build-depend on those.  (A<br>
> > simple script, perhaps packaged as a cargo helper command, could<br>
> > automatically translate the dependencies in Cargo.toml into<br>
> > Build-Depends suitable to update debian/control.)  We'll then need to<br>
> > rebuild dependent packages whenever we update to a new version of rustc,<br>
> > or potentially whenever their dependencies change; the latter depends on<br>
> > cargo's handling of pre-compiled library dependencies, as normally cargo<br>
> > rebuilds the entire dependency tree rooted at a binary to keep its<br>
> > dependencies consistent, and we may need to maintain that property<br>
> > ourselves within the Debian archive.  The current transition tracking<br>
> > mechanism (<a href="https://release.debian.org/transitions/" rel="noreferrer" target="_blank">https://release.debian.org/transitions/</a>) should handle that;<br>
> > Rust will likely end up on the list of "Permanent trackers" alongside<br>
> > Haskell and OCaml.<br>
> ><br>
> > In terms of future automation, we'll want to build a dh_cargo at some<br>
> > point, and it can just pass a standard set of options and paths to<br>
> > cargo.  Depending on the handling of library dependencies, we may also<br>
> > want to provide a substvar for debian/control, so that library -dev<br>
> > packages can have automatic Depends on their dependencies.<br>
> ><br>
> > - Josh Triplett<br>
> ><br>
> > _______________________________________________<br>
> > Pkg-rust-maintainers mailing list<br>
> > <a href="mailto:Pkg-rust-maintainers@lists.alioth.debian.org" target="_blank">Pkg-rust-maintainers@lists.alioth.debian.org</a><br>
> > <a href="https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers" rel="noreferrer" target="_blank">https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers</a><br>
> ><br>
</blockquote></div>