<div dir="ltr"><div class="gmail_quote">On Wed, 13 May 2015 at 08:47 Luca Bruno <<a href="mailto:lucab@debian.org">lucab@debian.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday 06 May 2015 05:10:45 Angus Lees wrote:<br>
<br>
I've been a bit busy recently with no time for pkg-rust, apologies for this<br>
late reply.<br>
<br>
> I've implemented the libstd-rust-$hash package as would be expected without<br>
> concern for release frequency because I would like to gain experience with<br>
> the "right" thing and have actual data before making compromises. If it<br>
> turns out we _are_ releasing "too frequently", I think our next best<br>
> alternative is to abandon the libstd-rust-$hash split out for now and just<br>
> roll the runtime libs into libstd-rust-dev, rather than making a non-soname<br>
> "libstd-rust" package. This alternative means we won't be able to depend<br>
> on dylibs from other Debian packages, which is the use case we expect to<br>
> not handle at present anyway. One day it is inevitable that we _will_ have<br>
> a package that needs the dylibs and then we won't have a choice, but this<br>
> alternative would let us postpone any maintenance costs until that day.<br>
<br>
Will cargo try to link stuff to libstd dylibs by default?<br></blockquote><div><br></div><div>cargo links the "<a href="http://build.rs">build.rs</a>" 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)</div><div><br></div><div>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.</div><div><br></div><div>(Oh, and rustc itself is linked dynamically of course - but it's ok for it to have a tight dependency on the -dev package ;)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If not, having only a libstd-rust-dev for the moment sounds like a good<br>
initial step.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Bikeshedding: rustlang-libstd-dev (or something similar)?<br>
python/ruby/golang/haskell have the langname as prefix.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>(Do we need "lang" or is "rust" sufficiently unambiguous?</div><div>Is it important that the -dev naming scheme can be extended to the hypothetical/future corresponding run-time dylib package name?)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> - rustc/rustdoc and -dev libraries are not installed with "1.0" in the path,<br>
> so can't be co-installed with some hypothetical 1.1 rustc release. Any<br>
> rust-built binaries can be built with different rust releases and<br>
> co-installed just fine, they'll just have conflicting build-deps (assuming<br>
> the libstd $hash gets bumped - we can force this if upstream doesn't for<br>
> some reason).<br>
<br>
This is probably something to revisit after "next stable after 1.0" to see how<br>
many things changes, but:<br>
* aren't we already versioning+symlinking rustdoc/rustc?<br></blockquote><div><br></div><div>Not in the multiarch branch (at present).</div><div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>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?)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* would abusing /etc/ld.so.conf.d/ with custom paths helps to avoid<br>
conflicting packages?<br></blockquote><div><br></div><div>(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 (?)</div><div><br></div><div>(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 :( )</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Proposal looks great. A bit complex, so I'm not sure I've grasped all the<br>
implications, but still +1 from me.<br></blockquote><div><br></div><div>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) ;)</div><div><br></div><div>(*) 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)...</div><div><br></div><div>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).</div><div><br></div><div> - Gus</div></div></div>