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

[Brian Anderson]

On Tue, Aug 30, 2016 at 7:27 AM, Sylvestre Ledru <s at mozilla.com> wrote:

> Le 30/08/2016 à 16:18, Henri Sivonen a écrit :
> >
> > On Fri, Aug 26, 2016 at 1:48 PM, Mike Hommey <mh at glandium.org> wrote:
> >> - By the time ESR requires rustc, it will require a very much more
> >>   recent version of rustc than the one in Debian stable. Rustc currently
> >>   only be compiled, at best, by the previous version. Which means either
> >>   building every released version of rustc between the one shipped in
> >>   Debian stable and the one required by ESR in sequence, or
> >>   bootstrapping rustc from scratch. (and same again a year later, when
> >>   the ESR version bumps)
> >
> > This would be neatly solved by Debian stable updating both Firefox and
> > rustc every six weeks like Debian stable updates our competitor
> > Chromium. (This would nicely also eliminate the complication of people
> > who want to write Rust code having to know to avoid from main and to
> > go to backports or to rustup.rs instead.)
> If we are talking about Firefox ESR, my expectation from my release
> manager pov
> is that we will use the same version of the rust compiler for the whole
> cycle.
> I don't want rust changing versions impacting a product that we want to be
> stable...
>
> Once an ESR cycle ends (they are shorter than Debian stable), well,
> bumping the rust
> dependency is going to be a pain because of the LLVM dependency...
> This is the core of the issue...
>

Is this implying that upgrading the Rust package alongside the new Firefox
ESR, within the Debian stable cycle, is doable? It's only upgrading the
LLVM dependency that is going to be problematic (and presumably libclang)?

If I understand how this is looking to play out, late 2017 Debian stable
will need to upgrade to its first Firefox ESR that depends on Rust. At that
time it will need to introduce rustc and cargo packages, that have
dependencies on _some version of LLVM_; it's also likely that at that time
m-c will depend on or vendor rust-bindgen and in turn creating a libclang
dependency. Is that right? Does introducing the rustc and cargo packages
mid-cycle pose a problem? If not, is figuring out how to accommodate the
Debian-stable LLVM and libclang the only major problem?

I might suggest we can solve the problem with LLVM by promising
compatibility with whatever LLVM Debian stable lands on, but I know LLVM
has some major IR changes coming that are likely to make that difficult.

With Thunderbird taking on a Rust dependency does that impact Debian's
anti-bundling policies? Do Thunderbird and Firefox share a gecko package?




>
>
> >> At this point, I'm thinking we might as well have a separate archive for
> >> Firefox only, that would autobuild the latest uploads of llvm, clang,
> >> rustc and Firefox in a Debian stable build environment.
>

Mike, does "separate archive" mean people would need to get their Firefox
debs from an unofficial source? Is this scheme problematic either
technically or politically?


> >
> > Building a dependency constellation of the latest (non-ESR) Firefox,
> > rustc, cargo, llvm and libclang appears to solve the problems, so it
> > seems like a reasonable solution. Why would it need to be in a
> > separate archive, though? Chromium already updates every six weeks in
> > main as opposed to a separate archive.
> AFAIK, Chromium doesn't have a dependency like Rust.
>

Can you expand on what you mean by "like Rust"? Is it that Rust is large,
that it's a compiler? How does the 6-week Chromium update scheme work with
their deps - are they bundled or do they have their own "constellation" of
packages only used by Chromium?


>
>
> > Old Ubuntu LTS seems to be able
> > to package a newer GCC within their main archive in order to build
> > non-ESR Firefox: http://packages.ubuntu.com/precise/gcc-mozilla .
> Ubuntu is not Debian ;)
>
> S
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20160830/9be1d717/attachment-0001.html>