[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