[Pkg-rust-maintainers] Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

[Josh Triplett]

On Fri, Aug 21, 2015 at 02:29:40AM +0000, Angus Lees wrote:
> On Fri, 21 Aug 2015 at 06:03 Josh Triplett <josh at joshtriplett.org> wrote:
> > Quite a bit of the Cargo ecosystem makes use of #![feature(...)] to
> > enable unstable features.  Rust release builds prohibit this by default:
> >
> >
> > /home/josh/.cargo/git/checkouts/rust-fuse-e03750e721e8762f/master/src/lib.rs:12:1:
> > 12:18 error: #[feature] may not be used on the stable release channel
> > /home/josh/.cargo/git/checkouts/rust-fuse-e03750e721e8762f/master/src/
> > lib.rs:12 #![feature(libc)]
> >
> >       ^~~~~~~~~~~~~~~~~
> >
> > Please consider providing a package of rustc that allows these
> > feature-gates.
> > (That doesn't necessarily have to be a nightly version.)
> >
> 
> Hrm.  I think this means you're asking for a rustc-nightly.deb - or some
> other arbitrary periodically updated snapshot of rustc compiled with
> --channel=nightly to "unlock" opt-in unstable features.
> 
> I can completely understand this desire, but I think this inconvenience is
> a completely desired outcome of the "Stability as a Deliverable" Rust
> strategy[1].  As a *distribution* I feel like shipping a nightly package
> would be directly subverting this strategy and as such I consider this a
> wishlist bug against the upstream policy/mechanism.

I *don't* think such a package should be in the stable distribution.
However, having it in experimental would be wildly useful.  I *really*
don't want to go grab binaries from upstream; I'd much rather install
through Debian.

> Personally, I'm reluctant to break the release-channels experiment so close
> to the 1.0 release.  We may well declare it failed and do something
> different in future, but right now I think Debian has an important role to
> play in demonstrating what the "stable" Rust world looks like and providing
> pressure for upstreams to avoid unstable features.

I don't think this would be breaking release-channels.  Rather, this
would be demonstrating the value of that model.  Debian unstable, and
thus testing and eventually stable, would get stable Rust releases.
Debian experimental would get Rust builds with experimental features
turned on.  Software uploaded to Debian unstable, for instance, would
still have to build with stable Rust.

As a related example, Debian ships Firefox "Extended Support Release"
builds in unstable, which migrate to testing and eventually stable.  But
in experimental, you can get the latest non-ESR release, and sometimes
betas.

> I hope you can understand why I'm going to close this upstream+wontfix - at
> least for now.  Please feel free to reopen and/or continue the discussion
> if you disagree.

I do disagree, as stated above.  I agree completely with Rust's
release-channel model; however, I think it's appropriate to ship
unstable Rust in experimental, and stable Rust in
unstable/testing/stable.

That said, I can completely understand if the Rust team doesn't have the
bandwidth to maintain an extra set of packages.  (Though, using it as a
canary seems like it may help you anticipate future upstream issues.)

- Josh Triplett