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

[Ximin Luo]

(removing Hans as promised in an earlier email)

Henri Sivonen:
> This thread stalled while waiting for new mailing list filters. Let's
> see if this goes through to the lists.
> 

It does seem like there is something holding these emails back. I'll keep everyone on CC including the lists until this is fixed.

> 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.)

Would the Firefox build process also require cargo? I know we're having some general difficulties with that, but others know the details better than I. Could you point us to a doc or describe in slightly more detail how the new build system works?

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

(Due to other things grabbing my attention, I don't have any other specific comments right now, I'm just fishing for info at the moment.)

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git