[Pkg-rust-maintainers] Facilitating Firefox+Rust Linux distro packaging
Brian Anderson
banderson at mozilla.com
Sat Nov 19 01:20:40 UTC 2016
On Tue, Nov 15, 2016 at 1:11 AM, Sylvestre Ledru <sylvestre at debian.org>
wrote:
> 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
>
>
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.
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.
>
> > 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20161118/b136545a/attachment-0001.html>
More information about the Pkg-rust-maintainers
mailing list