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

[Luca Bruno]

On Wednesday 06 May 2015 05:10:45 Angus Lees wrote:

I've been a bit busy recently with no time for pkg-rust, apologies for this 
late reply.

> I've implemented the libstd-rust-$hash package as would be expected without
> concern for release frequency because I would like to gain experience with
> the "right" thing and have actual data before making compromises.  If it
> turns out we _are_ releasing "too frequently",  I think our next best
> alternative is to abandon the libstd-rust-$hash split out for now and just
> roll the runtime libs into libstd-rust-dev, rather than making a non-soname
> "libstd-rust" package.  This alternative means we won't be able to depend
> on dylibs from other Debian packages, which is the use case we expect to
> not handle at present anyway.  One day it is inevitable that we _will_ have
> a package that needs the dylibs and then we won't have a choice, but this
> alternative would let us postpone any maintenance costs until that day.

Will cargo try to link stuff to libstd dylibs by default?

If not, having only a libstd-rust-dev for the moment sounds like a good 
initial step.

Bikeshedding: rustlang-libstd-dev (or something similar)? 
python/ruby/golang/haskell have the langname as prefix.

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

This is probably something to revisit after "next stable after 1.0" to see how 
many things changes, but:
 * aren't we already versioning+symlinking rustdoc/rustc?
 * would abusing /etc/ld.so.conf.d/ with custom paths helps to avoid
   conflicting packages? 

Proposal looks great. A bit complex, so I'm not sure I've grasped all the 
implications, but still +1 from me.


Cheers, Luca

-- 
 .''`.  ** 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