Hi all,
Well it's been quite a while since we talked about Debian's Firefox and Rust packaging. Maybe it's time to regroup and see what the status is.
On the Rust side we have configurations now for mips, mipsel, mips64el, ppc64, ppc64el, and s390x in tree. This is to make it easier for them to bootstrap on all their supported architectures. We don't quite have binaries that can be installed with rustup yet, but I'm working on that now.
Here are the major points at issue as I recall them:
- After the next Firefox ESR we're going to start requiring Rust. The next Firefox ESR is 52, which is already on aurara, and will be stable on 2017-03-07 (calendar) (hm, that's later than I realized). So it looks like right about now mozilla-central can start depending on Rust, and on 2017-04-18 there will be a stable release of Firefox that requires Rust.
- Debian has a stable freeze on Jan 5 2107, where they will presumably settle on Firefox 52 ESR as their stable release.
- In January 2018 there will be a new Firefox ESR which depends on Rust. There is not yet a plan for doing that upgrade, which will certainly require a new version of Rust, a new version of Clang, and a new version of LLVM.
- During the Debian stable freeze and subsequent release, there must be a strategy for maintaining Firefox and Rust in Debian unstable/testing. I believe the way forward here has not been clear either, and most discussion has been about maintaining the stable distro.
The problem we have focused on the most is that of upgrades to Firefox requiring not only Rust, but LLVM and Clang. In the stable distro, this would be an unprecedented amount of churn, and presumably on the testing distro will require great coordination.
The main solutions as I recall them were:
- Vendor evering with Firefox, rustc, Cargo, crates, llvm and clang. Really straightforward but distasteful to distros generally.
- Upgrade Rust while continuing to use the same LLVM. This solution is hard to count on because the work to keep Rust compatible with the older LLVM may be great. It's also unlikely that rust-bindgen will be compatible with whatever clang happens to be available.
- Create new rust, LLVM, and clang packages mid-release, just for the purposes of supporting the Firefox ESR upgrade.
- Switch off Firefox ESR's and establish an upgrade schedule, that matches Firefox's / Rust's, as policy exceptions. Similar to how chromium as managed, but the scale of software Firefox is upgrading is even larger (two compilers).
So I'm not coming with any new solutions. Just want to check in. Sylvestre, Gus, Mike, anybody else, is there any new information? Is the way forward any clearer now? How can we make it clear?
Based on the timelines I mentioned above I guess that there must be a solution by March 7, when Firefox 52 ESR is released. Do you agree that is the ultimate deadline? Is there an earlier practical deadline by which we will know we are in serious trouble if we don't yet have a solution?