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

[Josh Triplett]

On Sun, Dec 11, 2016 at 11:05:58AM +0000, Luca BRUNO wrote:
> On Saturday, 10 December 2016 12:06:22 UTC Josh Triplett wrote:
> 
> I think the draft is basically ready to go.
> I suggest you to post this to internals.rust-lang.org and reddit /r/rust to 
> hopefully gather some non-debian-biased reviews and a bit more exposure.

I'd planned to do so after we considered it ready; I'll do that shortly.

> > 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?
> 
> Starting from that PR, I've found and now linked-in 
> http://doc.crates.io/source-replacement.html#directory-sources

Ah, good find; thank you.

Unfortunately, that doesn't document the file checksum format, but since
we don't actually use that checksum format, that doesn't seem urgent to
fix.

> > 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.
> 
> Yes, I was mostly thinking about this second case. I think it is ok as worded 
> now, should work for most cases.

Thanks.

> > > (@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?
> >
> >  If we have some systematic way we want to tweak RUSTFLAGS, we'd probably do
> > that via dh-cargo.
> 
> Some kind of bridging between dpkg-buildflags and RUSTFLAGS.
> For example, cargo's debian/rules currently translates LDFLAGS into
> "-C link-arg" via RUSTFLAGS. It is perfectly fine for dh-cargo to do this. 

I'd hesitate to *mandate* applying all LDFLAGS to all Rust code without
some kind of review.  (Allowing individual packages to do that seems
fine.)  It also seems extremely easy to change later, since we would
only need to change dh-cargo and binNMU a few packages.

Can I suggest starting a thread on internals about whether any crates
(especially common crates) would break in any way if we systematically
applied -C link-args="-Wl,-z,relro -Wl,-z,now" to every build?  If the
conclusion comes back as "no, that shouldn't break anything", then let's
go ahead and enable it.  (You might also ask if it would make sense to
change rustc to enable both of those by default.)