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

[Luca Bruno]

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.

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 :).

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?

Cheers, Luca

PS. as Sylvestre have already noticed, I'm also available for
testing/discussion on IRC during most of daytime (UTC+1).

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.    | lucab (AT) debian.org
`. `'`                          | GPG Key ID: 0x4F3BBEBF
  `-     http://www.debian.org 	| Debian GNU/Linux Developer