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

Thu May 21 22:08:27 UTC 2015

On Thu, 21 May 2015 at 01:16 Jordan Justen <jljusten at gmail.com> wrote:

> On 2015-05-05 22:10:45, Angus Lees wrote:
> >    On Mon, 27 Apr 2015 at 20:03 Sylvestre Ledru <sylvestre at debian.org>
> wrote:
> >
> >      Le 27/04/2015 10:43, Angus Lees a A(c)critA :
> >
> >        On Mon, 27 Apr 2015 at 17:17 Sylvestre Ledru <
> sylvestre at debian.org>
> >        wrote:
> >
> >          I like the idea and I think it makes sense.
> >          I am just afraid about the libstd-$hash having to through new
> every
> >          time...
> >
> >        This shouldn't be any different to regular lib$soname bumps for
> >        C-based packages.
> >
> >      Except that they will change at every release for a while, don't you
> >      think?
> >
> >    Yes, it looks like the plan is to change the hash every release, which
> >    means every 6 weeks.
> >    I don't know what the threshold is for "too often", so we might need
> to
> >    just try this for a bit and see(?).
>

(First: thanks for reading the proposal)

> I still don't think it is a good idea to put lib*-hash* into the
> standard library paths.
>
> The rust team doesn't seem to recommend this yet.
>

Go seems to use private locations for libraries:
> https://packages.debian.org/jessie/amd64/golang-go-linux-amd64/filelist

I tried to follow the examples of other languages (particularly C/C++) when
writing the above, so these are good comparisons.

The golang-go-linux-amd64 libraries are all static libraries afaics - so I
think the more accurate comparison with Rust is rlibs, which are in a
similar private location in this proposal.

So does gcc:
> https://packages.debian.org/jessie/amd64/libgcc-4.8-dev/filelist

The few shared libraries in here (eg: libgcc_s.so) are actually symlinks
back to /lib/$multiarch/ (from the non -dev package).

Again, the more accurate comparison here is Rust compile-time dylibs. In
this proposal, the Rust compile-time dylibs are similarly in a private
location and symlinked back to the non -dev libraries in
/usr/lib/$multiarch/ for use by the run-time linker.

How will this libstd-rust-4e7c5e5c package possibly work? Once we rev
> the rustc source package to build libstd-rust-nexthash, it will no
> longer be possible to build/install the old package. So, what about
> packages that tried to depend on it?
>

Yes, they will be uninstallable and receive/need release-critical bugs
requesting them to be rebuilt.  This is similar to bumping ABI
compatibility in other C-family libraries.

Now if we _do_ want to avoid recompiling affected binaries then I think we
have to do the same things that C lib maintainers have to do (fork the
source package and continue to provide libstd-rust-$oldhash) - but I'm not
proposing that at all at this stage and we would only do this if we were
forced to for some reason.

I also don't understand why libstd-rust-4e7c5e5c will provide this
> binary: /usr/lib/x86_64-linux-gnu/libgraphviz-4e7c5e5c.so. How does
> this make sense?
>
> My thought is that perhaps libgraphviz-rust-1.0.so could make sense...
> Or, librust-1.0-graphviz.so?
>

Yeah, we could indeed break every library out, and I agree it makes some
sense to do so.  I felt this was too eager without some (eg) space-saving
use-case at this point - but we could certainly do this now if you want to.
  The packages should still interact with each other and multiarch concerns
in the same way, so I don't think there are any new surprises for us
when/if we go further down this path.

It is frustrating that the rust language is sending mixed messages on
> this issue. On the one hand they recommend *not* dynamically linking
> with rust at this time. On the other hand they put the libraries in
> the standard library paths and make it easy to depend on them.
>
> I think it the rust language needs to mature more to figure this issue
> out. Maybe rust is waiting for go to solve it first, so they can
> follow them? :) (Actually, not necessarily a bad plan.)
>

Yeah, agreed 100%.  I know one response I got from Rust upstreams was "wow,
you've certainly thought about this more than we have" ;)

 - Gus

> -Jordan
>
> >        A  I haven't maintained a C library package before, but afaik you
> only
> >        go through the NEW process for new source packages, not renamed
> binary
> >        packages.
> >
> >      No, ditto for renamed binaries.
> >
> >    Huh, I learnt something new :)
> >    Yes, the above means we'll need to go through the "binary-only"
> version of
> >    the NEW process for each new upstream release.A  Again, I don't know
> how
> >    much of a delay there will be in that.
> >    A ----------
> >    I've pushed an update that implements the proposal to a new
> >    alioth/multiarch branch.A  Let me know if you see any blockers to
> merging
> >    it onto master.A  The only lintian warnings currently are that
> >    rust-{gdb,lldb} don't have manpages, and that "epub" isn't a
> recognised
> >    doc-base format (I'm still unsure whether I want to file the feature
> >    request or just remove the epub doc-base entries).
> >    Re the libstd-rust-$hash package name: A  I attempted to name it just
> >    "libstd-rust" but this requires an additional "<< $next_upstream"
> >    dependency restriction in shlibs.A  We can add that, but doing so
> seemed
> >    to be strongly advised against in the library packaging guide that I
> was
> >    browsing through at the time - and they pointed to previous examples
> where
> >    not just using the soname as was intended led to various corner-case
> >    issues.
> >    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.A  If it turns out we _are_ releasing "too frequently", A
> 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.A  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.A  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.
> >    A - Gus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150521/07bffedf/attachment.html>