<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, 18 Jul 2016 at 15:31 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">A minor correction, and some preliminary investigation:<br>
<br>
On Sun, Jul 17, 2016 at 08:57:40PM -0700, Josh Triplett wrote:<br>> 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.<br></blockquote><div><br></div><div>Remember the *primary* reason we are bothering to do any of this is to be able to support a hypothetical security fix to an existing Rust library package 5 years from now.  We *must* be able to rebuild with patches.</div><div><br></div><div>If we could somehow guarantee that we would never ever need to modify any upstream Rust source code ever, then we could just vendor everything and go home (with some small impact on mirrors hosting Debian source packages).  Unfortunately, this is not the case.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> - 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.<br>
<br>
We can; I tested this, and I could "cargo package" each crate<br>
independently, which produced separate .crate files with a disjoint set<br>
of included sources.  I think we can either ship the resulting crates<br>
independently, or ship a package with multiple .crate.orig.tar.gz files<br>
that builds all the crates.  The former seems simpler, though the latter<br>
might help if a package expresses an exact version constraint on the<br>
crates it bundles.  Let's go with the former for now, until we run into<br>
a package that makes that problematic.<br></blockquote><div><br></div><div>>From my earlier exploration, it seemed ~common for a single upstream github repo to produce multiple <a href="http://crates.io">crates.io</a> crates, each with separate version numbers, and for the github repo to not have any sort of tag/branch that corresponded with whatever was uploaded to <a href="http://crates.io">crates.io</a>.  My conclusion at the time was that we had to package what was published on <a href="http://crates.io">crates.io</a>, and basically ignore whatever original common source tree they may or may not have been produced from.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> - -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.<br>
<br>
It looks like libgit2-sys supports an environment variable to use<br>
pkg-config to find libgit2; if set, it completely ignores its built-in<br>
copy of libgit2, which means we can avoid shipping that copy entirely.<br>
<br>
However, that means we'll need that environment variable set when<br>
building packages of bin crates that incorporate libgit2-sys (by way of<br>
git2-rs).  That seems like a pain.<br>
<br>
One possible proposal: librust-libgit2-sys-dev can have a Depends on<br>
libgit2-dev, and can ship a file<br>
/usr/share/rust/env.d/libgit2-sys-$version.conf (near the installed<br>
Cargo directory registry in /usr/share/rust/cargo/), which contains<br>
"LIBGIT2_SYS_USE_PKG_CONFIG=1".<br></blockquote><div><br></div><div>.. or we just patch the Debian version of librust-libgit2-sys-dev's <a href="http://build.rs">build.rs</a> to always use the system version.  Realistically, we probably want to strip the vendored C sources out of most of the *-sys crates when packaging, since Build-Deps can guarantee the system library is present, and actually removing the files means we can avoid auditing them for licenses, etc.</div><div><br></div><div>Many of the other *-sys crates I looked at earlier used pkg-config if available, so using the system library versions Just Worked.</div><div><br></div><div> - Gus</div></div></div>