[Pkg-rust-maintainers] On rust library packages

[Angus Lees]

Following on from my previous post about dylibs vs rlibs, I figure we have
these options for rust library packages:

1. Ship dylibs (and rlibs)

2. Ship rlibs only

3. Ship rust source (like golang library packages)

--------

Re (1):
I think (1) is out until we can provide ABI stability between compiler
releases somehow (see previous post).

Re (2):
As far as I can work out (and I've asked a few upstream rust devs), rlibs
have all the same ABI compatibility issues as dylibs across compiler
versions.  This means that if we shipped *-dev packages with rlibs, it
would look like this:
- libfoo-dev Depends on specific rustc/libstd upstream version, produces an
rlib file that installs somewhere into the rustc search path(*)
- There is no libfoo  (and no shilibs files)
- bar-tool would Build-Depend on libfoo-dev (of correct libfoo upstream
version) but not on libfoo (since there is no such thing).

(*) rustc search path for rlibs is $prefix/lib/rustlib/$target/lib, but I
think this would be an easy/safe thing for us to extend in our rustc if we
wanted to look somewhere else for some reason.

This looks pretty good from a Debian packaging standpoint, although library
maintainers would need to rebuild fairly quickly following rustc releases
(we could also NMU since no source change would be necessary - assuming no
rustc syntax changes).
I think cargo assumes source code, however (but I'm not sure on this point
- worth following up on) - it would be nice if we could make cargo work
with just an .rlib and some sort of stub manifest.

Re (3):
This is the easiest and safest option, given that golang has already
demonstrated this path is acceptable.  In this version, all library
packages are just a copy of their source code installed into a
semi-standard place.
- libfoo-dev ships library source code.  Has a dependency on specific
compiler version range, if it has to deal with breaking rustc syntax
changes - similar but not same as (2)
- There is no libfoo (and no shlibs files) - same as (2)
- bar-tool Build-Depends on libfoo-dev but not on libfoo - same as (2)

The advantage of this approach, is that cargo can be made to work with it
by a small patch to cargo to look in /our/rust/lib/install/path/* for
additional toml manifests, a lot like the existing .cargo/config `paths`
option.


So I think our options are (2) or (3).  I think we should run these options
past rust+cargo upstream since they both (presumably) require at least
small patches to cargo and it would make sense to match what other distros
might do.

 - Gus

(Thanks for reading.  I've been thinking about this for a few weeks now and
it was time I brought it to wider discussion)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150216/f96205b1/attachment.html>