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

[Angus Lees]

On Wed, 13 May 2015 at 08:47 Luca Bruno <lucab at debian.org> wrote:

> 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?
>

cargo links the "build.rs" build script dynamically - not for any strong
reason, although it is only used fleetingly during the build process so ABI
stability is not a concern.  (ie: dynamic linking should be ok and probably
gives a small build space+time improvement)

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.

(Oh, and rustc itself is linked dynamically of course - but it's ok for it
to have a tight dependency on the -dev package ;)

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

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.

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

Yeah, I was grouping rust naming conventions with C/C++ soname-derived
conventions rather than the interpreted languages, but I agree the -dev
package (in particular) is entirely rust-specific.  I'm fine with anywhere
on this naming spectrum.

(Do we need "lang" or is "rust" sufficiently unambiguous?
Is it important that the -dev naming scheme can be extended to the
hypothetical/future corresponding run-time dylib package name?)

> - 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?
>

Not in the multiarch branch (at present).

The _libraries_ are named uniquely (by hash) for each release, so don't
need an explicit 1.0 in their path.  This also means no rpath requirement,
which is nice (and makes cargo work again).

I was redoing all the paths and install steps anyway for multiarch, and it
was easier to drop the -1.0 symlinking for _executables_ at the same time
(it also removed a few "no manpage for rustc-1.0, etc" lintian warnings).

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

 * would abusing /etc/ld.so.conf.d/ with custom paths helps to avoid
>    conflicting packages?
>

(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 (?)

(In particular, we can't modify ld.so.conf.d dynamically based on whether
you invoked rustc-1.0 or rustc-1.1.  If we did want to do that, the best
way would be to make rustc-$v a wrapper script that set LD_LIBRARY_PATH and
rustc -C args.  Then any executable built with that would similarly need to
set LD_LIBRARY_PATH (similar to some of what libtool does now for C shared
libraries).  I think we just get more and more complex as we go further
down that rabbit hole :(  )

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

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

(*) Being sure to preserve the recent copyright, etc changes.   Looking at
the calendar, that puts it right on rust 1.0 launch.  I can merge pre or
post 1.0 launch, but I don't think the upstream milestone really has that
much affect on our ongoing packaging efforts (it's just like another beta
release for us)...

The good news is that users are just using any of this via the
"/usr/bin/rustc" entrypoint.  I think what we have demonstrated is that we
can experiment with different packaging layouts without breaking downstream
users (not that there are many of those atm).

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150513/a6820214/attachment.html>