<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hello,<br>
<br>
I like the idea and I think it makes sense.<br>
I am just afraid about the libstd-$hash having to through new
every time...<br>
Did you try to update the packaging with these changes to see if
there are any unexpected blockers?<br>
<br>
About co instability, I am not sure we have to rush on it.<br>
<br>
Good job!<br>
<br>
Cheers,<br>
Sylvestre<br>
<br>
<br>
Le 24/04/2015 12:28, Angus Lees a écrit :<br>
</div>
<blockquote
cite="mid:CAPA_H3fo9Y8vzrenkEYZ_-bWqPKSxo26AD2L6yvS-xWqWjvhgA@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true" href="http://architecture.mk">architecture.mk</a>
Makefile snippet that generates $rust_triple for Debian
platforms (like dpkg-dev's <a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Pkg-rust-maintainers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pkg-rust-maintainers@lists.alioth.debian.org">Pkg-rust-maintainers@lists.alioth.debian.org</a>
<a class="moz-txt-link-freetext" href="https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers">https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers</a>
</pre>
</blockquote>
<br>
</body>
</html>