[Pkg-rust-maintainers] Facilitating Firefox+Rust Linux distro packaging

Sylvestre Ledru sylvestre at debian.org
Tue Nov 15 09:11:45 UTC 2016


Hello

+ Julien who recently joined Mozilla as a release manager...
Who happens to be part of the Debian release management team too.

Le 15/11/2016 à 02:30, Brian Anderson a écrit :
> 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.
Good, we have arm64, amd64 and i386 currently. Having binaries simplifies our life a lot for
porting (afaik, we haven't investigating doing a full manual port).


> 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 aurora, 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.
> 
> [calendar]: https://wiki.mozilla.org/RapidRelease/Calendar
> 
> 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:
> 
> 1) Vendor evering with Firefox, rustc, Cargo, crates, llvm and clang. Really
>   straightforward but distasteful to distros generally.
> 2) 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.
> 3) Create new rust, LLVM, and clang packages mid-release, just for the purposes
>   of supporting the Firefox ESR upgrade.
> 4) 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?
This is an excellent summary. As packager of Rust and LLVM/clang, the option 3) sounds
reasonable if we can get an approval of the Debian release management and security teams.

LLVM/Clang won't be an issue as they can be co-installed. We might have the issue that the LLVM/Clang version requires
a specific version of g++ not available in the archive at the time.
For the rust compiler, two things:
* we don't have any(?) packages using rust in the Debian archive yet. I am not expecting something important
before the freeze
* we have to make sure that cargo can be built with the future version of rust which would be in the archive


> 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?
> 
> 
> On Fri, Sep 2, 2016 at 12:44 AM, Henri Sivonen <hsivonen at mozilla.com <mailto:hsivonen at mozilla.com>> wrote:
> 
>     On Thu, Sep 1, 2016 at 11:12 AM, Ximin Luo <infinity0 at debian.org <mailto:infinity0 at debian.org>> wrote:
>     > Henri, am I right to summarise your proposal as:
> 
>     No.
> 
>     My main points are:
> 
>      1) Debian has already committed to deviating from its general policy
>     by shipping Firefox ESR-major-to-next-ESR-major updates within the
>     lifetime of a Debian release. (And already deviates from its general
>     policy to a *greater extent* [in opposite directions] for all other
>     Web browsers.)
> 
>      2) An ESR-major-to-next-ESR-major update will (with such high
>     probability that should be planned for) require a rustc update.
> 
>      3) rustc and rust-bindgen updates across the timespan involved in
>     ESR-major-to-next-ESR-major update may (with such high probability
>     that should be planned for) require an llvm/clang update.
> 
>      4) Debian already has the packaging infrastructure to make shipping
>     another LLVM version in addition to the multiple LLVM versions already
>     present in a release *technically feasible*.
> 
>      5) Given that we are talking about *technically feasible* things as
>     *build dependencies* for a *Web browser* and given that Debian already
>     deviates from its *general* policy for *all* Web browsers, I think
>     it's reasonable that Debian deviate from its general rules in a
>     similar manner for the *build dependencies* of a *Web browser*.
> 
>     Ancillary points:
> 
>      6) Given that a newer rustc compiles the programs that an older rustc
>     did and given that an old rustc sticking around risks holding back the
>     Rust ecosystem, it would be nice if Debian updates rustc on the same
>     schedule as it updates Chromium.
> 
>      7) Updating rustc every six weeks would also avoid having to
>     re-bootstrap from upstream.
> 
>     > 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?
> 
>     I'm especially *not* saying that point releases of a given major ESR
>     release would need either rustc or llvm updates.
> 
>     >> there wouldn't be a rustc bump over many versions.
>     >
>     > 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.
> 
>     I see. Let's ignore my ancillary points then.
> 
>     >> Debian already has the technical means of shipping multiple
>     >> side-by-side llvm-x.y and clang-x.y packages. It looks to me it would
>     >> be technically possible to promote an additional llvm-x.y & clang-x.y
>     >> package set from unstable to stable during the lifetime of stable.
>     >
>     > 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?
> 
>     Let's assume for now that the version of llvm required by rustc and
>     the version of libclang required by rust-bindgen match. In that
>     scenario, do you then have technical reasons (I mean reasons other
>     than policy reasons) why it wouldn't be workable for Debian to promote
>     another llvm-x.y package and clang-x.y (for same x in both and same y
>     in both) from unstable to already-released stable as build
>     dependencies of a rustc and rust-bindgen update?
> 
>     It's been already noted that it would be a problem if the new version
>     of llvm no longer compiled with the versions of gcc and libstd++ in
>     stable main, which is why I pointed out earlier in this thread that as
>     a contingency measure, the newer llvm/clang pair could be built with
>     an older in-archive clang (and potentially libc++) in that case.
> 
>     So I'm suggesting:
> 
>     if (next major Firefox ESR compiles with the same rustc and
>     rust-bindgen as the currently-in-Debian-stable major Firefox ESR) {
>       // Extremely unlikely, but let's include this case for completeness
>       return;
>     }
>     update rustc to what the new major ESR requires;
>     update rust-bindgen to what the new major ESR requires;
>     if (rustc and rust-bindgen work with llvm and clang that are already
>     in Debian stable) {
>       return;
>     }
>     // Assume unstable has a couple of the latest llvm/clang releases and
>     rustc/rust-bindgen can work with at least one of them
>     if (suitable llvm and clang in Debian unstable compiles with the
>     latest GCC&libstd++ in stable) {
>       promote the suitable llvm and clang pair from unstable to stable;
>       return;
>     }
>     promote the suitable llvm and clang pair from unstable to stable with
>     the gcc build dependency replaced with older clang (and, if needed,
>     libstdc++ dependency replaced with libc++);
>     return;
> 
>     > 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.
>     >
>     > 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.
> 
>     I see. Let's ignore my ancillary points then.
> 
>     On Thu, Sep 1, 2016 at 12:36 PM, Sylvestre Ledru <s at mozilla.com <mailto:s at mozilla.com>> wrote:
>     > I am sorry Henri but I am not sure to understand what you are trying to do
>     > in this thread.
> 
>     I'm trying to point out that Debian's policy constraints have
>     precedent for flexibility on the topic of Web browsers, so
>     accommodating Firefox's new needs should be within possibility
>     policy-wise, and that Debian's precedent for how llvm and clang are
>     packaged already goes a long way technically towards what's needed, so
>     Firefox's needs aren't technically ocean-boiling, either.
> 
>     > All Debian Developer on this thread knows very well Debian and our
>     > constraints.
> 
>     I think referring to constraints opaquely isn't particularly helpful.
>     Especially when the usual constraints already don't fully apply to any
>     Web browsers in Debian, it seems better to talk about the
>     applicability of particular constraints.
> 
>     --
>     Henri Sivonen
>     hsivonen at mozilla.com <mailto:hsivonen at mozilla.com>
> 
> 
> 
> 
> _______________________________________________
> Pkg-rust-maintainers mailing list
> Pkg-rust-maintainers at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-rust-maintainers
> 




More information about the Pkg-rust-maintainers mailing list