<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 26, 2016 at 3:48 AM, Mike Hommey <span dir="ltr"><<a href="mailto:mh@glandium.org" target="_blank">mh@glandium.org</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 Fri, Aug 26, 2016 at 04:17:57AM +0000, Angus Lees wrote:<br>
> Now: if we're updating ESR firefox and that requires newer rustc, then<br>
> we'll need to distribute that newer rustc in the same way as any other new<br>
</span>> build-deps required by the new ESR version.  That's fine and normal (...)<br>
<br>
Except it has technical challenges.<br>
<br>
- Timing-wise we're kind of lucky, because by the time an ESR requires<br>
  rustc, Debian stable will have shipped a rustc compiler.<br>
<br>
BUT<br>
<br>
- Debian oldstable (today's stable), which will likely still be supported,<br>
  won't have one. Which means either dropping support for a modern web<br>
  browser in oldstable, or bootstrapping rustc in oldstable.<br>
<br>
- By the time ESR requires rustc, it will require a very much more<br>
  recent version of rustc than the one in Debian stable. Rustc currently<br>
  only be compiled, at best, by the previous version. Which means either<br>
  building every released version of rustc between the one shipped in<br>
  Debian stable and the one required by ESR in sequence, or<br>
  bootstrapping rustc from scratch. (and same again a year later, when<br>
  the ESR version bumps)<br>
<br>
- By the time ESR requires rustc, the rustc version it requires will<br>
  need a version of LLVM very much more recent than the one in Debian<br>
  stable. Which means backporting a new version of LLVM as well. (and<br>
  the same again a year later, when the ESR version bumps)<br>
<br>
Now, to add fun to the mix, like there wasn't enough:<br>
<br>
- By the time ESR requires rustc, it will also require rust-bindgen.<br>
  Which in turn requires libclang.<br>
<br>
At this point, I'm thinking we might as well have a separate archive for<br>
Firefox only, that would autobuild the latest uploads of llvm, clang,<br>
rustc and Firefox in a Debian stable build environment.<br>
<br>
Or not ship Firefox at all, and "rely" on snap, flatpak, etc. or on<br>
people using "testing".<br></blockquote><div><br><br></div><div>Oh, I missed this suggestion before but it actually seems like this situation is the poster-child for the snap/flatpak use-case. What's the story for those in Debian? Since we have basically one year to solve this problem, is there any chance we can come up with a working flatpak package in that time that will work for Debian, and possibly other distros?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Mike<br>
</font></span><br>
PS: I'm almost not joking.<br>
</blockquote></div><br></div></div>