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

[Angus Lees]

On Mon, 18 Jul 2016 at 15:31 Josh Triplett <josh at joshtriplett.org> wrote:

> A minor correction, and some preliminary investigation:
>
> On Sun, Jul 17, 2016 at 08:57:40PM -0700, Josh Triplett wrote:
> > 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.
>

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.

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.

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

>From my earlier exploration, it seemed ~common for a single upstream github
repo to produce multiple crates.io 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 crates.io.  My conclusion at the
time was that we had to package what was published on crates.io, and
basically ignore whatever original common source tree they may or may not
have been produced from.

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

.. or we just patch the Debian version of librust-libgit2-sys-dev's build.rs
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.

Many of the other *-sys crates I looked at earlier used pkg-config if
available, so using the system library versions Just Worked.

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20160719/9a5eb66e/attachment.html>