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

Tue Nov 15 01:30:29 UTC 2016

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.

[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:

- 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?

On Fri, Sep 2, 2016 at 12:44 AM, Henri Sivonen <hsivonen at mozilla.com> wrote:

> On Thu, Sep 1, 2016 at 11:12 AM, Ximin Luo <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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20161114/4d6e840d/attachment-0001.html>