<div dir="ltr">Hi all,<br><br>Well it's been quite a while since we talked about Debian's Firefox and Rust<br>packaging. Maybe it's time to regroup and see what the status is.<br><br>On the Rust side we have configurations now for mips, mipsel, mips64el, ppc64,<br>ppc64el, and s390x in tree. This is to make it easier for them to bootstrap on<br>all their supported architectures. We don't quite have binaries that can be<br>installed with rustup yet, but I'm working on that now.<br><br>Here are the major points at issue as I recall them:<br><br>- After the next Firefox ESR we're going to start requiring Rust. The next<br>  Firefox ESR is 52, which is already on aurara, and will be stable on<br>  2017-03-07 ([calendar]) (hm, that's later than I realized). So it looks like<br>  right about now mozilla-central can start depending on Rust, and on 2017-04-18<br>  there will be a stable release of Firefox that requires Rust.<br>- Debian has a stable freeze on Jan 5 2107, where they will presumably settle on<br>  Firefox 52 ESR as their stable release.<br>- In January 2018 there will be a new Firefox ESR which depends on Rust.<br>  There is not yet a plan for doing that upgrade, which will certainly require<br>  a new version of Rust, a new version of Clang, and a new version of LLVM.<br>- During the Debian stable freeze and subsequent release, there must be a strategy<br>  for maintaining Firefox and Rust in Debian unstable/testing. I believe the<br>  way forward here has not been clear either, and most discussion has been about<br>  maintaining the stable distro.<br><br>[calendar]: <a href="https://wiki.mozilla.org/RapidRelease/Calendar">https://wiki.mozilla.org/RapidRelease/Calendar</a><br><br>The problem we have focused on the most is that of upgrades to Firefox requiring<br>not only Rust, but LLVM and Clang. In the stable distro, this would be an<br>unprecedented amount of churn, and presumably on the testing distro will require<br>great coordination.<br><br>The main solutions as I recall them were:<br><br>- Vendor evering with Firefox, rustc, Cargo, crates, llvm and clang. Really<br>  straightforward but distasteful to distros generally.<br>- Upgrade Rust while continuing to use the same LLVM. This solution is hard to<br>  count on because the work to keep Rust compatible with the older LLVM may be<br>  great. It's also unlikely that rust-bindgen will be compatible with whatever<br>  clang happens to be available.<br>- Create new rust, LLVM, and clang packages mid-release, just for the purposes<br>  of supporting the Firefox ESR upgrade.<br>- Switch _off_ Firefox ESR's and establish an upgrade schedule, that matches<br>  Firefox's / Rust's, as policy exceptions. Similar to how chromium as managed,<br>  but the scale of software Firefox is upgrading is even larger (two compilers).<br><br>So I'm not coming with any new solutions. Just want to check in. Sylvestre, Gus,<br>Mike, anybody else, is there any new information? Is the way forward any clearer<br>now? How can we make it clear?<br><br>Based on the timelines I mentioned above I guess that there must be a solution<br>by March 7, when Firefox 52 ESR is released. Do you agree that is the ultimate<br>deadline? Is there an earlier practical deadline by which we will know we are in<br>serious trouble if we don't yet have a solution?<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 2, 2016 at 12:44 AM, Henri Sivonen <span dir="ltr"><<a href="mailto:hsivonen@mozilla.com" target="_blank">hsivonen@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Sep 1, 2016 at 11:12 AM, Ximin Luo <<a href="mailto:infinity0@debian.org">infinity0@debian.org</a>> wrote:<br>
> Henri, am I right to summarise your proposal as:<br>
<br>
</span>No.<br>
<br>
My main points are:<br>
<br>
 1) Debian has already committed to deviating from its general policy<br>
by shipping Firefox ESR-major-to-next-ESR-major updates within the<br>
lifetime of a Debian release. (And already deviates from its general<br>
policy to a *greater extent* [in opposite directions] for all other<br>
Web browsers.)<br>
<br>
 2) An ESR-major-to-next-ESR-major update will (with such high<br>
probability that should be planned for) require a rustc update.<br>
<br>
 3) rustc and rust-bindgen updates across the timespan involved in<br>
ESR-major-to-next-ESR-major update may (with such high probability<br>
that should be planned for) require an llvm/clang update.<br>
<br>
 4) Debian already has the packaging infrastructure to make shipping<br>
another LLVM version in addition to the multiple LLVM versions already<br>
present in a release *technically feasible*.<br>
<br>
 5) Given that we are talking about *technically feasible* things as<br>
*build dependencies* for a *Web browser* and given that Debian already<br>
deviates from its *general* policy for *all* Web browsers, I think<br>
it's reasonable that Debian deviate from its general rules in a<br>
similar manner for the *build dependencies* of a *Web browser*.<br>
<br>
Ancillary points:<br>
<br>
 6) Given that a newer rustc compiles the programs that an older rustc<br>
did and given that an old rustc sticking around risks holding back the<br>
Rust ecosystem, it would be nice if Debian updates rustc on the same<br>
schedule as it updates Chromium.<br>
<br>
 7) Updating rustc every six weeks would also avoid having to<br>
re-bootstrap from upstream.<br>
<span class=""><br>
> In this case, what *is* the difference between firefox and firefox-esr? In other words, does doing (3) not break your own principles on what firefox-esr should be about?<br>
<br>
</span>I'm especially *not* saying that point releases of a given major ESR<br>
release would need either rustc or llvm updates.<br>
<span class=""><br>
>> there wouldn't be a rustc bump over many versions.<br>
><br>
> As I mentioned earlier: having to re-bootstrap rustc from upstream to allow non-consecutive rustc version upgrades, I think is not a major problem for Debian stable or Debian in general.<br>
<br>
</span>I see. Let's ignore my ancillary points then.<br>
<span class=""><br>
>> Debian already has the technical means of shipping multiple<br>
>> side-by-side llvm-x.y and clang-x.y packages. It looks to me it would<br>
>> be technically possible to promote an additional llvm-x.y & clang-x.y<br>
>> package set from unstable to stable during the lifetime of stable.<br>
><br>
> Doing this multiple times raises the costs for Debian. It would really reduce our (and other distros') work if (for firefox-esr) rustc and rust-bindgen could depend on the same LLVM version. What are the costs for arranging this on your side?<br>
<br>
</span>Let's assume for now that the version of llvm required by rustc and<br>
the version of libclang required by rust-bindgen match. In that<br>
scenario, do you then have technical reasons (I mean reasons other<br>
than policy reasons) why it wouldn't be workable for Debian to promote<br>
another llvm-x.y package and clang-x.y (for same x in both and same y<br>
in both) from unstable to already-released stable as build<br>
dependencies of a rustc and rust-bindgen update?<br>
<br>
It's been already noted that it would be a problem if the new version<br>
of llvm no longer compiled with the versions of gcc and libstd++ in<br>
stable main, which is why I pointed out earlier in this thread that as<br>
a contingency measure, the newer llvm/clang pair could be built with<br>
an older in-archive clang (and potentially libc++) in that case.<br>
<br>
So I'm suggesting:<br>
<br>
if (next major Firefox ESR compiles with the same rustc and<br>
rust-bindgen as the currently-in-Debian-stable major Firefox ESR) {<br>
  // Extremely unlikely, but let's include this case for completeness<br>
  return;<br>
}<br>
update rustc to what the new major ESR requires;<br>
update rust-bindgen to what the new major ESR requires;<br>
if (rustc and rust-bindgen work with llvm and clang that are already<br>
in Debian stable) {<br>
  return;<br>
}<br>
// Assume unstable has a couple of the latest llvm/clang releases and<br>
rustc/rust-bindgen can work with at least one of them<br>
if (suitable llvm and clang in Debian unstable compiles with the<br>
latest GCC&libstd++ in stable) {<br>
  promote the suitable llvm and clang pair from unstable to stable;<br>
  return;<br>
}<br>
promote the suitable llvm and clang pair from unstable to stable with<br>
the gcc build dependency replaced with older clang (and, if needed,<br>
libstdc++ dependency replaced with libc++);<br>
return;<br>
<span class=""><br>
> Debian stable users should not be using /usr/bin/rustc for anything other than building Debian stable packages. We can make that very clear in the documentation and/or print giant warning signs, if that would make sense to you.<br>
><br>
> For the purpose of interoperating with the rustc upstream ecosystem (or others), yes everyone should use Debian testing/unstable. In my personal opinion, we really need to rename "stable" "testing" etc to make this more obvious.<br>
<br>
</span>I see. Let's ignore my ancillary points then.<br>
<span class=""><br>
On Thu, Sep 1, 2016 at 12:36 PM, Sylvestre Ledru <<a href="mailto:s@mozilla.com">s@mozilla.com</a>> wrote:<br>
> I am sorry Henri but I am not sure to understand what you are trying to do<br>
> in this thread.<br>
<br>
</span>I'm trying to point out that Debian's policy constraints have<br>
precedent for flexibility on the topic of Web browsers, so<br>
accommodating Firefox's new needs should be within possibility<br>
policy-wise, and that Debian's precedent for how llvm and clang are<br>
packaged already goes a long way technically towards what's needed, so<br>
Firefox's needs aren't technically ocean-boiling, either.<br>
<span class=""><br>
> All Debian Developer on this thread knows very well Debian and our<br>
> constraints.<br>
<br>
</span>I think referring to constraints opaquely isn't particularly helpful.<br>
Especially when the usual constraints already don't fully apply to any<br>
Web browsers in Debian, it seems better to talk about the<br>
applicability of particular constraints.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Henri Sivonen<br>
<a href="mailto:hsivonen@mozilla.com">hsivonen@mozilla.com</a><br>
</font></span></blockquote></div><br></div>