<div dir="ltr">What do you think of the following?  I'll write it up in wiki form after the discussion shakes out anything terribly wrong.<div><br></div><div><br></div><div><b>libstd-$hash</b> - runtime libraries (required by ~nothing except rustc itself yet)</div><div><br></div><div>- Contains dylibs installed into <b>/usr/lib/$mutliarch_triple/</b> (importantly: this is in ld.so library path, so no rpath modifications required downstream).</div><div>- Multi-Arch: same</div><div>- Includes Debian shlibs file with very specific version (because no ABI guarantees).</div><div>- 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.</div><div>- 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.</div><div>   - 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).</div><div><br></div><div><b>libstd-rust-dev</b> - dev libraries (rlib/dylib - required to compile)</div><div><br></div><div>- Contains rlibs/dylibs installed into <b>/usr/lib/rustlib/$rust_triple/</b></div><div>- Multi-Arch: same, thanks to 1:1 with debian arch and $rust_triple</div><div>- dylibs are symlinks to the same files in libstd-$hash</div><div>- 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.</div><div>- 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.</div><div><br></div><div><b>lbstd-rust-multiarch-dev</b> - rlib/dylibs for non-Debian archs</div><div><br></div><div>- Contains rlibs and dylibs for non-Debian architectures, still installed into <b>/usr/lib/rustlib/$rust_triple/</b><br></div><div>- Architecture: all; Multi-Arch: foreign, since the files are opaque binary data to any particular Debian architecture</div><div>- dylibs are not symlinks, since there is no corresponding non-dev package</div><div><br></div><div><b>rustc</b> - compiler, built with support for all cross compile targets</div><div><br></div><div>- Package contains <b>/usr/bin/{rustc,rustdoc}</b></div><div>- Multi-Arch: foreign</div><div>- Strict version dependency on libstd-rust-$hash and libstd-rust-dev from the same rustc release</div><div>- Compiled with support for all valid targets (?? Size impact needs to be investigated - we may want a separate rustc-multiarch that Provides: rustc)</div><div>- Debian package includes a /usr/share/rust/<a href="http://architecture.mk">architecture.mk</a> Makefile snippet that generates $rust_triple for Debian platforms (like dpkg-dev's <a href="http://architecture.mk">architecture.mk</a>).  Useful for rustc and future Debian Rust packages.</div><div><br></div><div><b>rust-doc</b> - docs</div><div><br></div><div>- Contains docs (duh) installed into <b>/usr/share/doc/rust-doc/</b></div><div>- Architecture: all; Multi-Arch: foreign</div><div><br></div><div><b>rust-{gdb,lldb}</b> - debugger shell wrappers and pretty printers</div><div><br></div><div>- Package contains <b>/usr/bin/rust-{gdb,lldb}</b> and pretty printers in <b>/usr/share/rust-{gdb,lldb}/</b> (unless there's a more standard place for $debugger)</div><div>- 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?)</div><div><br></div><div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>I think the potentially controversial changes from the current packaging are:<br></div><div>- dylibs are in ld.so path rather than hidden away and using rpath</div><div>- 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).</div><div><div><br></div><div>Objections?</div><div><br></div><div> - Gus</div></div></div>