[Pkg-rust-maintainers] Rust multiarch-friendly package/filesystem layout proposal

[Angus Lees]

What do you think of the following?  I'll write it up in wiki form after
the discussion shakes out anything terribly wrong.


*libstd-$hash* - runtime libraries (required by ~nothing except rustc
itself yet)

- Contains dylibs installed into */usr/lib/$mutliarch_triple/*
(importantly: this is in ld.so library path, so no rpath modifications
required downstream).
- Multi-Arch: same
- Includes Debian shlibs file with very specific version (because no ABI
guarantees).
- Includes $hash in the package name (and library file names) because we
may need multiple versions of these installed in parallel from different
rust versions.
- Unsure where/whether "rust" should appear in the package name.  Pros:
Regular solib Debian policy would say we call it just "libstd-$hash", so
this is what I'm proposing here.  Not having "rust" in the name extends
naturally to hypothetical C plugin libraries (pam, nss, pkcs11, etc) that
just happen to have been built using rust, which is nice.  Cons: "libstd"
is ridiculously generic.
   - Another possible option is to not include "rust" in the name for other
future hypothetical rust libraries, but make a one-off exception for this
particular package (ie: libstd-rust-$hash or similar).

*libstd-rust-dev* - dev libraries (rlib/dylib - required to compile)

- Contains rlibs/dylibs installed into */usr/lib/rustlib/$rust_triple/*
- Multi-Arch: same, thanks to 1:1 with debian arch and $rust_triple
- dylibs are symlinks to the same files in libstd-$hash
- Filenames are versioned (with hash), but package name is not.  Unsure of
rustc behaviour when finding two crates with same name.  May want to
revisit and include $hash in package name if we find this has sensible
behaviour.
- Again unsure where/whether "rust" should appear in the package name.
Unlike the runtime library package however, this one clearly has no use
other than when compiling Rust source, so I've included "rust" here.

*lbstd-rust-multiarch-dev* - rlib/dylibs for non-Debian archs

- Contains rlibs and dylibs for non-Debian architectures, still installed
into */usr/lib/rustlib/$rust_triple/*
- Architecture: all; Multi-Arch: foreign, since the files are opaque binary
data to any particular Debian architecture
- dylibs are not symlinks, since there is no corresponding non-dev package

*rustc* - compiler, built with support for all cross compile targets

- Package contains */usr/bin/{rustc,rustdoc}*
- Multi-Arch: foreign
- Strict version dependency on libstd-rust-$hash and libstd-rust-dev from
the same rustc release
- Compiled with support for all valid targets (?? Size impact needs to be
investigated - we may want a separate rustc-multiarch that Provides: rustc)
- Debian package includes a /usr/share/rust/architecture.mk Makefile
snippet that generates $rust_triple for Debian platforms (like dpkg-dev's
architecture.mk).  Useful for rustc and future Debian Rust packages.

*rust-doc* - docs

- Contains docs (duh) installed into */usr/share/doc/rust-doc/*
- Architecture: all; Multi-Arch: foreign

*rust-{gdb,lldb}* - debugger shell wrappers and pretty printers

- Package contains */usr/bin/rust-{gdb,lldb}* and pretty printers in
*/usr/share/rust-{gdb,lldb}/* (unless there's a more standard place for
$debugger)
- Multi-arch: foreign; Architecture: *any*  (<- Note not "all"!  Required
to get transitive dependency on correct gdb/lldb architecture.
Alternatively, we go for Architecture:all and just assume no-one will
depend on rust-gdb?)


In case it isn't obvious, I'm trying to treat the dylib library packages
like a regular C/C++ .so library, that just has a narrow shlibdeps (because
ABI instability).

Basically to compile anything (native or cross-compile), you need
libstd-rust-$hash + libstd-rust-dev for the target architecture and rustc
for the build architecture (and rustc for build arch in turn depends on
libstd-rust-$hash for build arch).  The resulting executable will run on
$target arch. The rare cases that need to link against a rustc dylib
(compiler plugin?) will pick up a dependency on the specific
libstd-rust-$hash version via regular dpkg-shlibdeps (and will need to be
rebuilt whenever we move to a new rustc version).

I think the potentially controversial changes from the current packaging
are:
- dylibs are in ld.so path rather than hidden away and using rpath
- rustc/rustdoc and -dev libraries are not installed with "1.0" in the
path, so can't be co-installed with some hypothetical 1.1 rustc release.
Any rust-built binaries can be built with different rust releases and
co-installed just fine, they'll just have conflicting build-deps (assuming
the libstd $hash gets bumped - we can force this if upstream doesn't for
some reason).

Objections?

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