[Pkg-rust-maintainers] Hi :)

[Angus Lees]

I'm excited by Rust and glad to see this packaging effort spring back to
(visible) life.  Over the last month or so, I've been trying to build my
own rustc packages, and it's well past time that I made contact with the
rest of you.

The main differences with the current packaging and mine are:

 (1) I build-dep on a hypothetical existing rustc package by default and
use build profiles to skip this and download stage0 at build time for
bootstrapping.

The two modes work very cleanly from a packaging pov, but of course we
aren't going to have a stable rustc that we can use to build the next
compiler any time soon.  I was imagining that we'd be stuck in experimental
until we could build ongoing releases without binary blobs - but if we have
agreement from ftp-masters on the embedded-stage0-blob approach then
perhaps we don't want this part.

 (2) I split it out into separate librust-std "runtime" package, rustdoc,
rust-gdb, rust-lldb, etc packages

Do we think this is a good idea, or is the simple rustc/rust-doc split
easier for everyone to manage (users too)?

The rust-gdb/rust-lldb packages are trivial and mostly just broken out to
get the dependencies on gdb/lldb correct.

librust-std-xxx library package may or may not be a bad idea.  Most of my
packaging challenges have been around this package and shlibs files, given
that rust .so's lack SONAMEs.  The discussion I just had on #rust led to
the conclusion that rust binaries should be statically built for now.  This
means we might even want to not ship the .so's at all - and build
rustc/rustdoc statically.  That's a topic for some other post however.


More mundanely, I haven't maintained a package so closely with others
before - what's the usual workflow?  Should I push up a git branch or
something for review, use a git repo hosted somewhere else, or ... ?

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-rust-maintainers/attachments/20150129/0a06afc8/attachment.html>