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

Henri Sivonen hsivonen at mozilla.com
Wed Aug 24 10:47:21 UTC 2016

On Wed, Aug 24, 2016 at 12:43 PM, Ximin Luo <infinity0 at debian.org> wrote:
>> To address a previously-raised point about ABI:
>> I think it's best to proceed with the assumption that Rust will become
>> a mandatory build dependency for Firefox very soon. Meanwhile there
>> doesn't appear to be a Rust ABI freeze coming up by then. So I think
>> it does not make sense to expect Rust to have a frozen ABI by the time
>> Firefox requires Rust to build.
>> Firefox is going to bundle/vendor Rust code that exists standalone
>> crates on crates.io into the mozilla-central repo. Builds produced by
>> Mozilla will statically link this Rust code into libxul. Even if
>> Debian did the work to extract the bundled crates back into distinct
>> source packages, it's likely impractical to expect to be able to ship
>> Rust crates as distinct Debian binary packages providing dynamically
>> linkable libraries by the time Firefox requires Rust.
>> In terms of what precedent to look for, I think it makes sense to look
>> at Go library packaging rather than C library packaging as precedent
>> for Rust crates. As for rustc & cargo themselves, they are evolving at
>> fast enough pace that freezing them for the lifetime of Debian stable
>> is unlikely to serve either of the most realistic use cases: 1)
>> building Firefox, which updates at least by ESR jumps during the
>> lifetime of Debian stable or 2) developing software in Rust. In that
>> sense, to have rustc and cargo packages that are useful for the most
>> realistic near-term use cases, it makes sense to look at Chromium for
>> precedent for updates.
> This isn't the ideal situation, but as you note yes it has been done elsewhere like Chromium. It's less of a problem if those crates are not in Debian elsewhere; it's duplicate copies that the security team doesn't like. Suppose you have 20 rust crates and critical security problems were found in 1 of them, are you able to release a new version of Firefox immediately? (I guess you have enough resources to do that, but in general Debian can't count on everyone to be able to do that.)

If Debian's anti-bundling policy is triggered only once there are
multiple apps that bundle the same dependency, it makes sense to just
let the firefox package bundle the Rust crates and worry about those
only if/when another Rust app that depends on some of the same crates
show up. As long as Debian doesn't package other apps depending on the
same upstream crates, dealing with security bugs in the
Firefox-bundled crates would be no different from dealing with
security bugs in Firefox-only C++ code.

> Would the Firefox build process also require cargo?

Yes. The Rust code is Firefox is built with Cargo.

> I know we're having some general difficulties with that, but others know the details better than I.

Difficulties other than contacting crates.io at build time? Mozilla's
build bots aren't allowed to contact crates.io, either, and Cargo
recently gained the capability not to contact crates.io.

> Could you point us to a doc or describe in slightly more detail how the new build system works?

and the bugs referenced by the post.

> Is this situation going to apply to other Mozilla products like Thunderbird/Icedove also?

Thunderbird is becoming less of a "Mozilla product" than it has been.
I don't really know what has happened in terms of Thunderbird
independence / governance spin-off since
. I can't see a difference in how the code is being worked on.

It's best to ask the Thunderbird folks what their plans are.

I'm working on Rust code that I plan to land in Gecko and that code,
once landed, is not going to be optional, so if Thunderbird doesn't
fork Gecko by the time mandatory Rust code lands in Gecko, Rust code
is going to be mandatory for Thunderbird in practice.

Henri Sivonen
hsivonen at mozilla.com

More information about the Pkg-rust-maintainers mailing list