<div dir="ltr">Oh, and I dropped libstd-rust-multiarch-dev. It turns out you need a C compilers available for any target (for lib{compiler-rt,morestack}.a), and when I went looking, Debian didn't seem to have compilers available for any of the non-Debian architectures (ios, android, etc). The exception was Windows/mingw, so I thought we might package up a libstd-rust-mingw-dev at some point but I haven't done so here.<div><br></div><div>From reading code and some quick experiments, I also discovered that rustc + system LLVM seem capable of compiling to all supported platforms out of the box - you just need to have the relevant target libs available (and building additional libs is the only thing the ./configure --target option ends up doing). So there is zero increase in rustc.deb size over what we were already building before. If you didn't already know about it, rustc also the ability to define new platform triples (that use already supported cpu architectures) by dropping JSON definition files into a particular directory - but I haven't tried this myself yet.<br><div><br></div><div> - Gus</div></div></div><br><div class="gmail_quote">On Wed, 6 May 2015 at 15:10 Angus Lees <<a href="mailto:gus@debian.org">gus@debian.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote">On Mon, 27 Apr 2015 at 20:03 Sylvestre Ledru <<a href="mailto:sylvestre@debian.org" target="_blank">sylvestre@debian.org</a>> wrote:<br></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<div>Le 27/04/2015 10:43, Angus Lees a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">On Mon, 27 Apr 2015 at 17:17 Sylvestre
Ledru <<a href="mailto:sylvestre@debian.org" target="_blank">sylvestre@debian.org</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>I like the idea and I think it makes sense.<br>
I am just afraid about the libstd-$hash having to
through new every time...<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>This shouldn't be any different to regular lib$soname
bumps for C-based packages.</div>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000">
Except that they will change at every release for a while, don't you
think?</div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Yes, it looks like the plan is to change the hash every release, which means every 6 weeks.</div><div><br></div><div>I don't know what the threshold is for "too often", so we might need to just try this for a bit and see(?).</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div> 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.</div>
</div>
</div>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000">
No, ditto for renamed binaries.</div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Huh, I learnt something new :)</div><div>Yes, the above means we'll need to go through the "binary-only" version of the NEW process for each new upstream release. Again, I don't know how much of a delay there will be in that.</div><div><br></div><div> ----------</div><div><br></div><div>I've pushed an update that implements the proposal to a new alioth/multiarch branch. Let me know if you see any blockers to merging it onto master. 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).</div><div><br></div><div><br></div><div>Re the libstd-rust-$hash package name: I attempted to name it just "libstd-rust" but this requires an additional "<< $next_upstream" dependency restriction in shlibs. 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.</div><div><br></div><div>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. If it turns out we _are_ releasing "too frequently", 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. 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. 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.</div><div><br></div><div> - Gus</div></div></div></blockquote></div>