<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 15, 2016 at 1:11 AM, Sylvestre Ledru <span dir="ltr"><<a href="mailto:sylvestre@debian.org" target="_blank">sylvestre@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello<br>
<br>
+ Julien who recently joined Mozilla as a release manager...<br>
Who happens to be part of the Debian release management team too.<br>
<span class=""><br>
Le 15/11/2016 à 02:30, Brian Anderson a écrit :<br>
> 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>
</span>Good, we have arm64, amd64 and i386 currently. Having binaries simplifies our life a lot for<br>
porting (afaik, we haven't investigating doing a full manual port).<br>
<span class=""><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>
</span>> Firefox ESR is 52, which is already on aurora, and will be stable on<br>
<span class="">> 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" rel="noreferrer" target="_blank">https://wiki.mozilla.org/<wbr>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>
</span>> 1) Vendor evering with Firefox, rustc, Cargo, crates, llvm and clang. Really<br>
<span class="">> straightforward but distasteful to distros generally.<br>
</span>> 2) Upgrade Rust while continuing to use the same LLVM. This solution is hard to<br>
<span class="">> 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>
</span>> 3) Create new rust, LLVM, and clang packages mid-release, just for the purposes<br>
<span class="">> of supporting the Firefox ESR upgrade.<br>
</span>> 4) Switch _off_ Firefox ESR's and establish an upgrade schedule, that matches<br>
<span class="">> 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>
</span>This is an excellent summary. As packager of Rust and LLVM/clang, the option 3) sounds<br>
reasonable if we can get an approval of the Debian release management and security teams.<br>
<br>
LLVM/Clang won't be an issue as they can be co-installed. We might have the issue that the LLVM/Clang version requires<br>
a specific version of g++ not available in the archive at the time.<br>
For the rust compiler, two things:<br>
* we don't have any(?) packages using rust in the Debian archive yet. I am not expecting something important<br>
before the freeze<br></blockquote><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* we have to make sure that cargo can be built with the future version of rust which would be in the archive<br>
<span class=""><br></span></blockquote><div><br></div><div>I would expect Debian to upgrade Cargo too. Cargo and Rust are somewhat coupled by both their features and their release process, and I consider mixing arbitrary cargo's with arbitrary rustc's to be unsupported.<br><br></div><div>In the future I'd like to have a simplified release process that includes the entire rust platform, rustc, cargo today, but also rustfmt, the rls, and clippy, in a single build.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<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>
><br>
</span>> On Fri, Sep 2, 2016 at 12:44 AM, Henri Sivonen <<a href="mailto:hsivonen@mozilla.com">hsivonen@mozilla.com</a> <mailto:<a href="mailto:hsivonen@mozilla.com">hsivonen@mozilla.com</a>>> wrote:<br>
<div><div class="h5">><br>
> On Thu, Sep 1, 2016 at 11:12 AM, Ximin Luo <<a href="mailto:infinity0@debian.org">infinity0@debian.org</a> <mailto:<a href="mailto:infinity0@debian.org">infinity0@debian.org</a>>> wrote:<br>
> > Henri, am I right to summarise your proposal as:<br>
><br>
> 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>
><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>
> I'm especially *not* saying that point releases of a given major ESR<br>
> release would need either rustc or llvm updates.<br>
><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>
> I see. Let's ignore my ancillary points then.<br>
><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>
> 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>
><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>
> I see. Let's ignore my ancillary points then.<br>
><br>
</div></div><span class="">> On Thu, Sep 1, 2016 at 12:36 PM, Sylvestre Ledru <<a href="mailto:s@mozilla.com">s@mozilla.com</a> <mailto:<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>
> 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>
><br>
> > All Debian Developer on this thread knows very well Debian and our<br>
> > constraints.<br>
><br>
> 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>
><br>
> --<br>
> Henri Sivonen<br>
</span>> <a href="mailto:hsivonen@mozilla.com">hsivonen@mozilla.com</a> <mailto:<a href="mailto:hsivonen@mozilla.com">hsivonen@mozilla.com</a>><br>
><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Pkg-rust-maintainers mailing list<br>
> <a href="mailto:Pkg-rust-maintainers@lists.alioth.debian.org">Pkg-rust-maintainers@lists.<wbr>alioth.debian.org</a><br>
> <a href="https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers" rel="noreferrer" target="_blank">https://lists.alioth.debian.<wbr>org/mailman/listinfo/pkg-rust-<wbr>maintainers</a><br>
><br>
<br>
</blockquote></div><br></div></div>