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

[Sylvestre Ledru]

On 23/01/2015 01:26, Jordan Justen wrote:
> 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 think it is the key point.
If upstream is going to change everything after the release of 1.0. I
think they should
remain private. If it is kind of stable, we could go public (especially
in experimental).
Myself, I don't really mind about rpath.

For now, I have the feeling that it should remain private until we know
more.
Things might be clearer once rust is accepted in Debian.

>> 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.
Yes, update alternatives for compiler does not really work:
https://bugs.launchpad.net/ubuntu/+source/llvm-3.1/+bug/991493
Moreover over, this is going to be hard to manage with the two libs
publics (except
if we rename them)
> 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.
>
I am happy about rust as a package name. It is clear enough
and we can always rename it if needed.

Sylvestre

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