[Pkg-rust-maintainers] On files location and rpath

[Jordan Justen]

On 2015-01-22 13:49:44, Luca Bruno wrote:
> Hi,
> I'm getting more to the point of binary package structure, and there are 
> some details I still don't grasp. (I had a look at the upstream binary
> installer and I think they are mostly doing it the right way, which 
> I'd like to follow).
> 
> Let's start by runtime .so libs - why are we hiding libstd/libterm/etc 
> away from a loadable path? I consider them generic runtime libs that 
> may be loaded by whatever binaries, and this way we are forcing all dynamic 
> binaries to carry an rpath which is mostly debian specific, rustc included.

It doesn't sound like the rust devs consider these libraries
stable. For one thing, they static link by default:
https://github.com/rust-lang/rust/issues/10209

For another thing, the libraries are libfoo-hash.so. So, dynamically
linking to one will break when rust 1.0.1 is released.

I'm was dissappointed to see this situation with rust, but from the
bug link above, it seems like the rust devs just decided not to solve
and standardize dynamic linking for rust 1.0.

I found that the debian ubuntu PPA was installing under
/usr/lib/*/rust, and it seemed to make sense given the various signs
that dynamic linking is not a good idea for rust at this point.

If we install under the system lib and run rustc, you'll still get a
statically linked executable. You have to run
"rustc -C prefer-dynamic foo.rs" to get a dynamically linked
executable.

If we don't install under the system lib, you can still produce a
dynamically linked executable. You need to run
"rustc -C prefer-dynamic -C rpath foo.rs"

Another thought on this is that installing these libraries privately
may be the more conservative choice to start with. If they are under
the system library path, then it could be more difficult to remove
them later.

> About the rest of the .so libs - arguably librustc_* may be considered 
> as private to rustc and moved away in a private path (with a custom 
> rpath only on rustc).
> I'm not 100% sure where to draw the line there though, and upstream 
> seems to ship them all in the loadable path: I read this as "they are 
> public libs" but we may ask them for clarification if you see it 
> differently.
> 
> About .so libs in rustlib/ - I think my memory is failing a bit here. 
> I seem to remember that this was for some corner-cases where rustc and 
> installed runtime were at different versions, but without an rpath 
> set on rustc this theory doesn't compute. 
> Also, they are bitwise identical to stuff in the loadable path, so I
> fear I may be missing something more tricky here.
> (if/when we split rustc from rust-runtime, we may want to split the two
> set and pin rustc to its private libraries via an absolute rpath, to 
> better decouple upgrades and runtime co-installability).
> 
> About .rlib libs in rustlib/ - these were introduce quite recently 
> so I may be off here. IIRC these are a middle ground between shared 
> and dynamic, and only needed at build time. So we may keep 
> them out of loadble paths, but we have to pay extra-attention to where 
> rustc/cargo/other will expect them to be.
> 
> About the executables - I don't understand the reasoning behind this:
> """
> $ ls -l /usr/bin/rustc*
> lrwxrwxrwx 1 root root  9 Jan 22 20:22 /usr/bin/rustc -> rustc-1.0
> lrwxrwxrwx 1 root root 42 Jan 22 20:22 /usr/bin/rustc-1.0 -> ../lib/x86_64-linux-gnu/rust/1.0/bin/rustc
> """
> I may see the point of hiding rustc behind a versioned symlink,
> but I miss why the original binary is under /usr/lib.
> Is it for some kind of multiarch compatibility or whatever other reason?
> (I'm not an expert in multiarch binaries :).

I don't think debian has multiarch binaries figured out. :)

Anyway, with the ubuntu PPA, they have a nightly package, and a stable
package. You can install both, and then use update-alternatives to
choose between them. I'm not sure that will be something we want, so I
didn't bother with the update-alternatives part.

Looking at gcc & clang, however, it does seem like installing rust 1.0
and rust 1.1 might be of interest. That is another reason why I tried
to install under the /usr/lib/$arch/rust/$version directory.

> Sorry for sounding very picky (I don't want to), but I think I may
> be missing the technical reasons behind the above choices.
> 
> Speaking of minor stuff: I just realized upstream source tarball is 
> called "rustc" (but the binary installer is "rust") and we only ship
> a "rust" binary. Should we rename both source and binary package to 
> "rustc", also to avoid confusion between language and compiler/package?

There is also a rustdoc and rust-gdb binary.

I'm not sure what the best package organization would be. I don't
think having a 'rust' package would be a bad thing, even if it ends up
just being a pseudo package that depends on a rustc package.

-Jordan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150122/1a851d5d/attachment.sig>