<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, 24 Aug 2016 at 18:15 Henri Sivonen <<a href="mailto:hsivonen@mozilla.com">hsivonen@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This thread stalled while waiting for new mailing list filters. Let's<br>
see if this goes through to the lists.<br>
<br>
To address a previously-raised point about ABI:<br>
<br>
I think it's best to proceed with the assumption that Rust will become<br>
a mandatory build dependency for Firefox very soon. Meanwhile there<br>
doesn't appear to be a Rust ABI freeze coming up by then. So I think<br>
it does not make sense to expect Rust to have a frozen ABI by the time<br>
Firefox requires Rust to build.<br>
<br>
Firefox is going to bundle/vendor Rust code that exists standalone<br>
crates on <a href="http://crates.io" rel="noreferrer" target="_blank">crates.io</a> into the mozilla-central repo. Builds produced by<br>
Mozilla will statically link this Rust code into libxul. Even if<br>
Debian did the work to extract the bundled crates back into distinct<br>
source packages, it's likely impractical to expect to be able to ship<br>
Rust crates as distinct Debian binary packages providing dynamically<br>
linkable libraries by the time Firefox requires Rust.<br></blockquote><div><br></div><div>As Ximin has said in his reply, I think this will be fine for Debian for the short term.  Under the general principal of "what if every package did that?" I think you can see that bundling isn't a long-term solution - but it is something we can overlook until this concern is non-theoretical.</div><div><br></div><div>I _believe_ that Fedora is stricter on anti-bundling and needs some sort of approval/exception before they will allow such a thing.  I don't want to ignorantly spread misinformation about Fedora policy but I believe whatever satisfies them will also be fine for Debian packaging.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In terms of what precedent to look for, I think it makes sense to look<br>
at Go library packaging rather than C library packaging as precedent<br>
for Rust crates.</blockquote><div><br></div><div>Agreed.   Rust Debian library "binary packages" will need to be source code and either dynamically linked with tight dependencies and the expectation that they are rebuilt frequently, or (much easier) statically linked.  We're just going to need to get used to recompiling things more often than we did with C/C++, and ensure the tooling is in place to automate that appropriately (all the pieces are pretty much there already).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As for rustc & cargo themselves, they are evolving at<br>
fast enough pace that freezing them for the lifetime of Debian stable<br>
is unlikely to serve either of the most realistic use cases: 1)<br>
building Firefox, which updates at least by ESR jumps during the<br>
lifetime of Debian stable or 2) developing software in Rust. In that<br>
sense, to have rustc and cargo packages that are useful for the most<br>
realistic near-term use cases, it makes sense to look at Chromium for<br>
precedent for updates.</blockquote><div><br></div><div>I think Debian stable "freezing Rust development" is a bit of a misconception that I'd like to squash.  You have given 2 different use cases, and they should be treated differently within Debian release management.</div><div><br></div><div>When a Debian release is made, it is effectively a snapshot of the archive at that point in time.  We need to be able to rebuild every package in that release using other packages in the same release for numerous practical and licensing reasons.  <span style="line-height:1.5">So: It is only relevant that any Rust application packages in a Debian release are able to be built with the rustc/cargo that was also captured in that snapshot.  </span><span style="line-height:1.5">Since the package versions were all captured concurrently, that will be the case.  Fast forward a hypothetical 10 years and it will still be possible to rebuild that Rust application when required, despite (theoretically) <a href="http://crates.io">crates.io</a> now being offline and the latest Rust-3000 being incompatible.   In particular, i</span><span style="line-height:1.5">t just doesn't matter that 10 year old rustc is unable to understand "modern" Rust-3000 syntax.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Now: if we're updating ESR firefox and that requires newer rustc, then we'll need to distribute that newer rustc in the same way as any other new build-deps required by the new ESR version.  That's fine and normal, but is *not* the same thing as helping end-users develop "modern" (ie: the moving target) Rust using the rustc in Debian stable.  This latter should be served by putting newer rustc/cargo releases into stable-backports, allowing users to choose whether "fixed point in time" or "keeping up with the community" is more important to them on a case-by-case basis.  We don't currently have rustc in -backports, but it's certainly something we should do, after getting cargo/rust in unstable ticking over smoothly.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">TL;DR: There are users who will want both "moving" and "don't change" cases from a rustc in a Debian stable release (indeed, I suspect "not changing" is more common for "stable", since desktop/devs are often on Debian "testing").  It is wrong to conclude that a release containing a snapshot of rustc is worthless just because the wider Rust community continues to move forward.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5"> - Gus</span></div></div></div>