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

[Sylvestre Ledru]

Hello,

I like the idea and I think it makes sense.
I am just afraid about the libstd-$hash having to through new every time...
Did you try to update the packaging with these changes to see if there
are any unexpected blockers?

About co instability, I am not sure we have to rush on it.

Good job!

Cheers,
Sylvestre


Le 24/04/2015 12:28, Angus Lees a écrit :
> 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
> <http://architecture.mk> Makefile snippet that generates $rust_triple
> for Debian platforms (like dpkg-dev's architecture.mk
> <http://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
>
>
> _______________________________________________
> Pkg-rust-maintainers mailing list
> Pkg-rust-maintainers at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers

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