[Pkg-rust-maintainers] Bug#860116: RFH: cargo -- Rust package manager

[Josh Triplett]

On Thu, Apr 20, 2017 at 08:16:00AM +0000, Ximin Luo wrote:
> Josh Triplett:
> > [..]
> > 
> > ...and looking at git from 20 minutes ago, it looks like you've switched
> > over to directory registries now.
> > 
> 
> Thanks for the tip, yes I figured this out by looking at both your dh-cargo code and also the Fedora cargo package. [1]
> 
> The new version is uploaded to experimental, but there's some more things I'd like to tidy up before uploading it to unstable.
> 
> - I get errors about missing "cargotest" and "hamcrest" when I try to `make test`, it looks like cargotest is actually in the rustc package:
> 
> https://github.com/rust-lang/rust/tree/master/src/tools/cargotest
> 
> Any suggestions on how to deal with this? I guess the obvious thing to do is to package a librust-cargotest-xxx-dev package but I wonder if there are better options.
> 
> - cargo still embeds libgit2-sys source code, and I can see that in the deps-tarball-filter.txt Luca was explicitly leaving it in. Is that because they patch the source code?
> 
> Can we just get rid of it, and link to libgit2 instead?

git2-rs doesn't modify libgit2, but it does use a snapshot from git, via
a submodule.  And unfortunately, while it supports building against a
system version via pkg-config, it doesn't include any version number in
its dependency.  libgit2 itself doesn't have a stable ABI, so either an
older *or* a newer version can potentially fail due to
incompatibilities.  (Also, like many libraries, libgit2 doesn't really
update its SONAME and similar except when releasing, even though many
people run git snapshots.)

Fortunately, git2-rs uses ctest now to attempt to make sure its bindings
match the actual signatures of the functions, so at least an attempt to
build against an older (or sometimes newer) version of libgit2 will tend
to produce compile errors (assuming you get all the environment
variables set correctly to find it).  However, I know of at least one
case where git2-rs pulled in a new snapshot of libgit2 to obtain
critical bugfixes rather than differences in ABI.

In short, I think we *could* switch to pulling in the system version of
libgit2, but we'd need to work very closely with the libgit2 maintainer,
and sometimes package snapshots of libgit2 from git.  We might also want
to work with libgit2 and git2-rs upstreams to 1) get more regular
updates to the version number that appears in the pkg-config file and 2)
get libgit2-sys to declare a pkg-config dependency that matches its
snapshot of libgit2.

- Josh Triplett