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

[Angus Lees]

On Wed, 24 Aug 2016 at 18:15 Henri Sivonen <hsivonen at mozilla.com> wrote:

> This thread stalled while waiting for new mailing list filters. Let's
> see if this goes through to the lists.
>
> 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.
>

As Ximin has said in his reply, I think this will be fine for Debian for
the short term.  Under the general principal of "what if every package did
that?" I think you can see that bundling isn't a long-term solution - but
it is something we can overlook until this concern is non-theoretical.

I _believe_ that Fedora is stricter on anti-bundling and needs some sort of
approval/exception before they will allow such a thing.  I don't want to
ignorantly spread misinformation about Fedora policy but I believe whatever
satisfies them will also be fine for Debian packaging.

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.


Agreed.   Rust Debian library "binary packages" will need to be source code
and either dynamically linked with tight dependencies and the expectation
that they are rebuilt frequently, or (much easier) statically linked.
We're just going to need to get used to recompiling things more often than
we did with C/C++, and ensure the tooling is in place to automate that
appropriately (all the pieces are pretty much there already).

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.


I think Debian stable "freezing Rust development" is a bit of a
misconception that I'd like to squash.  You have given 2 different use
cases, and they should be treated differently within Debian release
management.

When a Debian release is made, it is effectively a snapshot of the archive
at that point in time.  We need to be able to rebuild every package in that
release using other packages in the same release for numerous practical and
licensing reasons.  So: It is only relevant that any Rust application
packages in a Debian release are able to be built with the rustc/cargo that
was also captured in that snapshot.  Since the package versions were all
captured concurrently, that will be the case.  Fast forward a hypothetical
10 years and it will still be possible to rebuild that Rust application
when required, despite (theoretically) crates.io now being offline and the
latest Rust-3000 being incompatible.   In particular, it just doesn't
matter that 10 year old rustc is unable to understand "modern" Rust-3000
syntax.

Now: if we're updating ESR firefox and that requires newer rustc, then
we'll need to distribute that newer rustc in the same way as any other new
build-deps required by the new ESR version.  That's fine and normal, but is
*not* the same thing as helping end-users develop "modern" (ie: the moving
target) Rust using the rustc in Debian stable.  This latter should be
served by putting newer rustc/cargo releases into stable-backports,
allowing users to choose whether "fixed point in time" or "keeping up with
the community" is more important to them on a case-by-case basis.  We don't
currently have rustc in -backports, but it's certainly something we should
do, after getting cargo/rust in unstable ticking over smoothly.

TL;DR: There are users who will want both "moving" and "don't change" cases
from a rustc in a Debian stable release (indeed, I suspect "not changing"
is more common for "stable", since desktop/devs are often on Debian
"testing").  It is wrong to conclude that a release containing a snapshot
of rustc is worthless just because the wider Rust community continues to
move forward.

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20160826/b708680a/attachment-0001.html>