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

[Ximin Luo]

Josh Triplett:
> [..]
> 
> See my response to Ghislain elsewhere in this thread.
> 
> I've now fixed this in the policy, debcargo, and dh-cargo.
> 

Understood, thanks!

> [..]
> 
> Done.
> 
>>> The version constraints on those dependencies should ensure that the version satisfies the corresponding version predicates in Cargo.toml. 
>>
>> I suggest a minor change:
>>
>> The version constraints on those dependencies should usually ensure that the version satisfies the corresponding version predicates in Cargo.toml. You may deviate from this in reasonable situations, such as when upstream is declaring version constraints that are too strict for Debian's purposes. For example, due to the fact that Cargo doesn't allow you to express constraints regarding the rust version, cargo version, or versions of non-rust software that a crate uses, some upstream crate authors have chosen to declare too-strict version constraints on their crates. (Example #1 #2 etc). This is an inappropriate use of version constraints, because it interferes with the constraint-solving algorithms of the package manager - which may cause it to declare that a situation is unsolvable, when this is not true in the human "intuitive" sense (i.e. it would be solveable if the constraint was relaxed, requiring little to no other code changes). In such cases, the Debian packaging is positively encouraged to relax the upstream constraint. There may be other situations where upstream constraint relaxing is appropriate; if in doubt ask the mailing list.
>>
>> OK that was not so minor, I'm still pissed off at NodeJS. :) We can shorten the wording, but the "spirit" of the above should be in there somewhere IMO.
> 
> That doesn't quite work; the Debian version constraints need to pull in
> a package that satisfies the Cargo version predicates, or the package
> will fail to build.  If you want to build with a version outside those
> constraints, you can't just change the Debian version constraints; you
> have to change the Cargo version predicates as well.
> 

That is what I meant - this would include patching Cargo version dependencies.

I think we certainly should patch upstream in the cases that I described. If regex constraints itself to thread-local 0.2 simply to support older Rust versions, yet can compile perfectly fine against thread-local 0.3 (or can do so with trivial changes), this is definitely a constraint that we want to *dis*honour in Debian.

Otherwise we install two slightly different copies of the same thing, that has to both be tracked. That might sometimes be necessary in special situations, but not in this case - we'd be carrying the burden of this in Debian, due to holes in Cargo. I'd rather we expend the cost to undo this in advance, than leave extra work in the time-critical stressful situations that is security updates.

>>> These dependencies must satisfy the crate's [dependencies] and [build-dependencies] sections, including any architecture-specific or target-specific dependencies [..] including Windows
>>
>> In principle this would be good, but I wouldn't want us (Debian) to get into a situation where we're spending *too* much effort supporting cross-compilation to Windows. So I'm unsure about the "must". Requesting more comments from others here...
> 
> This is honestly easier to support than to not support, since library
> crates only ship source code.  We already need to support the target
> dependencies for any supported Debian architecture or OS; including the
> additional dependencies to support Windows adds a trivial number of
> crates.  Pruning out dependencies would require a pile of fiddly
> reverse-engineering of Cargo cfg expressions, just to eliminate
> build-time-only dependencies on a few bits of source code.
> 

That sounds fine. I was more worried about a potential future scenario where a whole new dependency tree of windows-only source packages need to be packaged. In that case, people should be sensible enough to ignore the "must" directive.

> [..]

Josh Triplett:
> On Thu, Dec 08, 2016 at 02:52:00AM +0000, Ximin Luo wrote:
>> [,,] 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
>>
>> [..]
> 
> 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.
> 

It doesn't need to be done through Cargo, it can be done through dpkg, using the same mechanism that buildinfo files use. In fact we would just intersect what goes in a buildinfo's Installed-Build-Depends with the-set-of-all-rust-crates.

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

This is also fine, and the release team uses dose3 and ben (ocaml tools). Possibly the haskell tooling also delegates to these.

Why I liked Built-Using, is that it's right there in the binary package and you don't have to do extra dependency calculations in the exact situations where you'd like to get these tasks done quickly. (You expend the cost earlier, in a less stressful period.) It also makes it very obvious to anyone looking at the binary package itself, "this needs to be rebuilt".

This would also be useful for normal DD packagers (non-security-team, non-transition, non-QA people) looking to upgrade their own packages. Instead of spending time to figure out how the tooling works, which might break up one's workflow e.g. if one does not normally do these tasks, one can just look at the Built-Using field.

It's not a major issue though, we don't need to spend too much time discussing this. If the tooling would be easy-to-use then I'd also be happy with that.

X

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