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

[Josh Triplett]

On Thu, Dec 08, 2016 at 02:21:00AM +0000, Ximin Luo wrote:
> Ghislain Vaillant:
> > I was about to ask the same thing as Ximin about the versioning.
> > 
> 
> It sounds like Josh is trying to justify it with this sentence: "Note that in both cases the version includes a .; Debian package names allow ., while Cargo crate and feature names do not, so this avoids any possible ambiguity between the versioned name of one crate package and the unversioned name of another crate package."
> 
> However, I can't understand what it means. That is possibly my fault, I don't know enough about Cargo nor its ecosystem yet. But it would be good to clarify this.

See my response to Ghislain elsewhere in this thread.

I've now fixed this in the policy, debcargo, and dh-cargo.

> > Also, may I suggest to recommend (not enforce) a naming scheme for the
> > source package as well. Something like rust-$(CRATE_NAME).
> > 
> > The reason for this is that a lot of the current crates are wrappers or
> > ports around existing libs and their name will likely collide with an
> > implementation in another language.
> > 
> > Python recommends using the python- prefix for source packages, ruby
> > enforces this with the ruby- prefix.
> > 
> 
> +1. Just to be clear, IMO this does not need to contradict the existing "Rust applications may use any package name" that you already put, I think this is OK too. So a "recommends" would be good.

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.

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

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

Thanks for your review.

- Josh Triplett