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

[Ximin Luo]

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.

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

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

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

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.

X

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