[Pkg-rust-maintainers] Draft Rust packaging policy for review

[Josh Triplett]

On Thu, Dec 08, 2016 at 02:52:00AM +0000, Ximin Luo wrote:
> Ximin Luo:
> > Everything else looks reasonable so far, taking into account that I'm not very familiar with Cargo yet. Hopefully others can also comment, to confirm that there's nothing major missing.
> > 
> 
> Oh, one thing that I forgot. Applications that are built out of crates will statically link in those crates, without needing a Depends: on them.
> 
> This will cause extra work for the security team, if a crate has a security vulnerability that must be patched in many packages.
> 
> We were discussing earlier in #debian-security what the best way is to make this sort of work easier. There is some precedence for adding Built-Using fields [1] to statically-linked binary packages, e.g. see the examples here:
> 
> https://wiki.debian.org/StaticLinking
> 
> and I had been doing this myself for some JS stuff that I helped with recently. But there were also people saying not to use this header, e.g.:
> 
> https://lists.debian.org/debian-haskell/2012/09/msg00037.html
> 
> Personally I think it's useful for this static-linking purpose.
> 
> An alternative is to detect it "automatically" by looking at the Build-Depends and assuming every crate-dev package will be statically linked into the resulting binaries. But then we still have to figure out what the versions were of those packages, that were used for the binary build. Our recent work on buildinfo files ([2], `man deb-buildinfo`) is able to supply this information, but it would be another download, and we haven't decided exactly how this would occur yet. So I think all-in-all the Built-Using option is simpler, at least for now.

Built-Using would require quite a lot more than that, because it would
need to recursively resolve the Build-Depends.  And that would need to
happen at build-time, because at debcargo-time, you don't know what
exact version you'll use.  Which would mean building a new Rust tool
available at build time that uses the Cargo API, because we don't want
to reinvent Cargo dependency resolution.  And that would introduce a
bootstrapping problem.

buildinfo seems like the more comprehensive solution for reproducible
builds and similar purposes, and we need it for all other packages
anyway.

For security-motivated rebuilds, or for transitions, I would suggest two
things:

- In the short-term, we will have a large number of library crate
  packages, but only a few Rust application packages.  (Off the top of
  my head: cargo, debcargo, rustup, ripgrep, git-series, and perhaps
  Firefox; of those, only a subset of those will appear in the next
  stable release.)  As long as that number remains small, I think we can
  easily handle such transitions/rebuilds manually.

- In the long-term, when we have a large number of application packages
  using Rust, we need the same kind of transition tooling that the
  Haskell packaging team has.  I mentioned one approach to such tooling
  in another mail in this thread.  I'd be happy to help develop this
  tooling, but I don't think we need to preemptively develop it to
  support half a dozen Rust application packages.