[Pkg-rust-maintainers] Rust multiarch-friendly package/filesystem layout proposal

[Luca Bruno]

On Wednesday 13 May 2015 01:03:24 Angus Lees wrote:

> I think the only use case that *requres* dylibs is someone who wants to
> package a "plugin" of any sort (eg PAM plugin, rustc compiler plugin, etc)
> - and we don't have any of those yet.

So we should be fine :)
 
> What do you think about running the experiment in the other direction?  If
> we combine the lib packages now, we will be uncertain about breaking them
> out again.  On the other hand, if we start off with them split out then
> we'll have direct first-hand experience with the tradeoff when/if we decide
> to combine them.

Of course we can start in both direction, as you prefer.
(NEW queue counter is around ~500 now btw)
 
> Bikeshedding: rustlang-libstd-dev (or something similar)?
> (Do we need "lang" or is "rust" sufficiently unambiguous?

rust seems to be enough.

> Is it important that the -dev naming scheme can be extended to the
> hypothetical/future corresponding run-time dylib package name?)

I'm not sure about this. Probably not?

> I could certainly put the version symlinks back in for rustc/rustdoc
> executables (and manpages), but I'm struggling to see the benefit -
> particularly when cargo, etc will only use the unqualified "rustc"
> executable afaics. 
> Is it actually a problem having versions of rustc
> conflict? (and if we do follow the rustc-1.0 approach, how does a
> cargo-using package find the right rustc executable without
> build-conflicting on all other rustc versions anyway?)

No, it won't at this point. Everything will be happy just calling rustc.
But all co-installable compilers do that, and probably we will too if/when we 
get there. As we had it so far, I saw no point in throwing it away (even if it 
won't be of any use right now).
 
> (Thinking...)  ld.so.conf.d only helps with run-time dylib paths .. so it
> won't help with rustc/rustdoc executables.  If we use ld.so.conf.d, then
> the dylibs will be available in the system-wide ld.so path anyway - in
> which case I think this is no different to just dropping them in
> /usr/lib/$multiarch/ directly (?)

I don't remember right now the usecase I had in mind, but your summary seems 
correct: it won't help.

> Thanks.  If there's no objections, I'll merge the multiarch branch across
> to master sometime next week(*). If you've got any unpushed commits, now
> might be a good time to flush them out (or do the rebase yourself) ;)

Nothing on my side, but Sylvestre is the one usually doing uploads and may 
have some stuff around.

-- 
 .''`.  ** 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150513/8a41e3cd/attachment.sig>