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

[Jordan Justen]

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

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

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

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?

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?

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

-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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150520/7425289f/attachment.sig>