[Pkg-rust-maintainers] Rust multiarch-friendly package/filesystem layout proposal
Angus Lees
gus at debian.org
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>
More information about the Pkg-rust-maintainers
mailing list