<div dir="ltr"><div class="gmail_quote">On Thu, 21 May 2015 at 01:16 Jordan Justen <<a href="mailto:jljusten@gmail.com">jljusten@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-05-05 22:10:45, Angus Lees wrote:<br>
> On Mon, 27 Apr 2015 at 20:03 Sylvestre Ledru <<a href="mailto:sylvestre@debian.org" target="_blank">sylvestre@debian.org</a>> wrote:<br>
><br>
> Le 27/04/2015 10:43, Angus Lees a A(c)critA :<br>
><br>
> On Mon, 27 Apr 2015 at 17:17 Sylvestre Ledru <<a href="mailto:sylvestre@debian.org" target="_blank">sylvestre@debian.org</a>><br>
> wrote:<br>
><br>
> I like the idea and I think it makes sense.<br>
> I am just afraid about the libstd-$hash having to through new every<br>
> time...<br>
><br>
> This shouldn't be any different to regular lib$soname bumps for<br>
> C-based packages.<br>
><br>
> Except that they will change at every release for a while, don't you<br>
> think?<br>
><br>
> Yes, it looks like the plan is to change the hash every release, which<br>
> means every 6 weeks.<br>
> I don't know what the threshold is for "too often", so we might need to<br>
> just try this for a bit and see(?).<br></blockquote><div> </div><div>(First: thanks for reading the proposal)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I still don't think it is a good idea to put lib*-hash* into the<br>
standard library paths.<br>
<br>
The rust team doesn't seem to recommend this yet.<br></blockquote><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Go seems to use private locations for libraries:<br>
<a href="https://packages.debian.org/jessie/amd64/golang-go-linux-amd64/filelist" target="_blank">https://packages.debian.org/jessie/amd64/golang-go-linux-amd64/filelist</a></blockquote><div><br></div><div>I tried to follow the examples of other languages (particularly C/C++) when writing the above, so these are good comparisons.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So does gcc:<br>
<a href="https://packages.debian.org/jessie/amd64/libgcc-4.8-dev/filelist" target="_blank">https://packages.debian.org/jessie/amd64/libgcc-4.8-dev/filelist</a></blockquote><div><br></div><div>The few shared libraries in here (eg: libgcc_s.so) are actually symlinks back to /lib/$multiarch/ (from the non -dev package).</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How will this libstd-rust-4e7c5e5c package possibly work? Once we rev<br>
the rustc source package to build libstd-rust-nexthash, it will no<br>
longer be possible to build/install the old package. So, what about<br>
packages that tried to depend on it?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I also don't understand why libstd-rust-4e7c5e5c will provide this<br>
binary: /usr/lib/x86_64-linux-gnu/libgraphviz-4e7c5e5c.so. How does<br>
this make sense?<br>
<br>
My thought is that perhaps <a href="http://libgraphviz-rust-1.0.so" target="_blank">libgraphviz-rust-1.0.so</a> could make sense...<br>
Or, <a href="http://librust-1.0-graphviz.so" target="_blank">librust-1.0-graphviz.so</a>?<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is frustrating that the rust language is sending mixed messages on<br>
this issue. On the one hand they recommend *not* dynamically linking<br>
with rust at this time. On the other hand they put the libraries in<br>
the standard library paths and make it easy to depend on them.<br>
<br>
I think it the rust language needs to mature more to figure this issue<br>
out. Maybe rust is waiting for go to solve it first, so they can<br>
follow them? :) (Actually, not necessarily a bad plan.)<br></blockquote><div><br></div><div>Yeah, agreed 100%. I know one response I got from Rust upstreams was "wow, you've certainly thought about this more than we have" ;)</div><div><br></div><div> - Gus</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Jordan<br>
<br>
> A I haven't maintained a C library package before, but afaik you only<br>
> go through the NEW process for new source packages, not renamed binary<br>
> packages.<br>
><br>
> No, ditto for renamed binaries.<br>
><br>
> Huh, I learnt something new :)<br>
> Yes, the above means we'll need to go through the "binary-only" version of<br>
> the NEW process for each new upstream release.A Again, I don't know how<br>
> much of a delay there will be in that.<br>
> A ----------<br>
> I've pushed an update that implements the proposal to a new<br>
> alioth/multiarch branch.A Let me know if you see any blockers to merging<br>
> it onto master.A The only lintian warnings currently are that<br>
> rust-{gdb,lldb} don't have manpages, and that "epub" isn't a recognised<br>
> doc-base format (I'm still unsure whether I want to file the feature<br>
> request or just remove the epub doc-base entries).<br>
> Re the libstd-rust-$hash package name: A I attempted to name it just<br>
> "libstd-rust" but this requires an additional "<< $next_upstream"<br>
> dependency restriction in shlibs.A We can add that, but doing so seemed<br>
> to be strongly advised against in the library packaging guide that I was<br>
> browsing through at the time - and they pointed to previous examples where<br>
> not just using the soname as was intended led to various corner-case<br>
> issues.<br>
> I've implemented the libstd-rust-$hash package as would be expected<br>
> without concern for release frequency because I would like to gain<br>
> experience with the "right" thing and have actual data before making<br>
> compromises.A If it turns out we _are_ releasing "too frequently", A I<br>
> think our next best alternative is to abandon the libstd-rust-$hash split<br>
> out for now and just roll the runtime libs into libstd-rust-dev, rather<br>
> than making a non-soname "libstd-rust" package.A This alternative means<br>
> we won't be able to depend on dylibs from other Debian packages, which is<br>
> the use case we expect to not handle at present anyway.A One day it is<br>
> inevitable that we _will_ have a package that needs the dylibs and then we<br>
> won't have a choice, but this alternative would let us postpone any<br>
> maintenance costs until that day.<br>
> A - Gus<br>
</blockquote></div></div>