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

[Josh Triplett]

On Sat, Dec 10, 2016 at 04:12:05PM +0000, Luca BRUNO wrote:
> On Tuesday, 6 December 2016 22:33:19 UTC Josh Triplett wrote:
> > I posted a preliminary draft for the Rust packaging policy at
> > https://wiki.debian.org/Teams/RustPackaging/Policy for review.
> 
> I'm really impressed by the level of this policy, thank you very much!

Thank you!

> I did a few minor wording adjustments directly on the page.
>
> I've also had a bunch of (non-blocking) doubts, so I've left several 
> questions/suggestions on that page, prefixed with a `@lucab`.
> Feel to directly amend/integrate the policy with those, or ask here if
> something is unclear. 

I've addressed all of those items, and made a few more minor wording
adjustments.

Quoting your comments here for more direct responses:

> @lucab: "if the crate contains both a bin and a lib section, it must
> follows the naming rules for library crates for its source and lib
> packages" added here perhaps?

I added a sentence addressing that; good idea.

> @lucab: should the original feature name be retain somewhere, eg in a
> X-header?

No, because we don't need it anywhere in the packaging, and anything
generating a dependency on it will apply the same transformation.  We
needed the original crate name in order to install the source in
/usr/share/cargo/registry/crate_name-version/ .

(In theory, dh-cargo could find the original crate name by parsing
Cargo.toml and finding the `name` key in the `[package]` section; in
practice, I don't want to add a dependency on a Perl TOML parser and
write more Perl in dh-cargo when I can instead write less Perl and do
the work in debcargo.)

> (@lucab: I think this whole mechanism is coming from cargo vendoring
> logic, do we have a reference we can link to?)

(In reference to directory registries.)

The only documentation I know of appears in
https://github.com/rust-lang/cargo/pull/2857 , which doesn't seem like
an appropriate place for the policy to link to.  Anyone want to submit a
patch to Cargo's documentation upstream incorporating a version of that?

> (@lucab: how do we signal when a library is meant for a specific arch
> or doesn't work on some arch? Example, an ARM-only GPIO lib)

For the "doesn't work" case (especially the "upstream doesn't know it
doesn't work" case that Debian so often detects on unusual
architectures), I think we don't; application packages depending on the
library will FTBFS on that architecture, architecture porters can
investigate and hopefully fix the library, and if they can't then they
can mark the application package as "not for us" or we can go to the
following case.

For the "can't ever work, by design" case: we still should leave the
library package "Architecture: all", because an application crate or
higher-level library crate might have an architecture-specific
dependency on it and only use it on that architecture.  If an
application crate has an unconditional dependency on that
architecture-specific library crate, then either we fix the application
to make the dependency conditional, or the application itself only runs
on that architecture and we should mark the *application* as
"Architecture: thatarch".

I added some text documenting how to handle that second case.  The first
case represents Debian's standard approach to porting and portability
for all types of packages, not specific to Rust.

> (@lucab: source packages should be built in cargo verbose mode,
> perhaps?)

Good idea.  I've added this to dh-cargo, and added it to the policy as a
"should".

> (@lucab: other flags that need to be specified? RUSTFLAGS inheriting
> LDFLAGS?)

No, not that I can think of.  Did you have anything specific in mind
here?

Most tweaks to rustc options would occur via build profiles in
Cargo.toml.  If an application package wants to tweak RUSTFLAGS via
debian/rules, it could certainly do so, though that seems odd.  If we
have some systematic way we want to tweak RUSTFLAGS, we'd probably do
that via dh-cargo.

- Josh Triplett