[rust-dev] stage0 in a post-rust-1.0 world

[rust-dev] stage0 in a post-rust-1.0 world

[Angus Lees]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

I wanted to remember how to be a Debian Developer, and rust-1.0 is coming
up, so I thought it was time to look into how one might package up rust for
a distribution (yes, I'm aware a few other DDs have looked at this earlier;
I've read some of their wiki pages/code but no, I haven't contacted them
yet).

Once rust is bootstrapped on a new distro/architecture, it would be nice to
be able to build a rust release using the regular rust compiler rather than
downloading a pre-built opaque stage0 blob.  How would this work in
practice?

Specifically, once we reach 1.0:
- Will the rust stage1 source be limited to using "stable" rust language
features?
- What sort of version skew between stage0 and stage1 will be supported?

Additionally, I currently see numerous "breaking" changes transitioned via
#[cfg(stage0)].  The assumption is that stage0 is older than the breaking
change, and stage1+ is newer than the change.  Amongst other things, this
means that you can't currently have the full compile-experience (using
--enable-local-rust) using a compiler that you've just built :(
I see there's already been discussion towards other mechanisms for tagging
version-specific code(*).  I'm new to the rust mailing list and community,
so mostly I'm just looking to get caught up on the conversations around
this and register a vote for "we need to have a story around this for 1.0,
and not later".

(*)
http://discuss.rust-lang.org/t/pre-rfc-rust-version-attribute-specifying-rust-language-version-within-source-code

 - Gus

[-- Attachment #2: Type: text/html, Size: 1876 bytes --]

Re: [rust-dev] stage0 in a post-rust-1.0 world

[Matthew McPherrin]

I absolutely believe rust needs to give up its snapshots to be sanely
and widely packaged, but when I mentioned this before, there didn't
seem to be a lot of traction for the idea.

In particular, the Rust team still plans to move much quicker than,
say, Debian releases new packages.  In that way, distribution
packaging is a negative:  Rust is far from "done", and having people
using even three month old compilers is likely to be a bad idea.


On Sat, Dec 20, 2014 at 11:29 PM, Angus Lees <gus@inodes.org> wrote:
> I wanted to remember how to be a Debian Developer, and rust-1.0 is coming
> up, so I thought it was time to look into how one might package up rust for
> a distribution (yes, I'm aware a few other DDs have looked at this earlier;
> I've read some of their wiki pages/code but no, I haven't contacted them
> yet).
>
> Once rust is bootstrapped on a new distro/architecture, it would be nice to
> be able to build a rust release using the regular rust compiler rather than
> downloading a pre-built opaque stage0 blob.  How would this work in
> practice?
>
> Specifically, once we reach 1.0:
> - Will the rust stage1 source be limited to using "stable" rust language
> features?
> - What sort of version skew between stage0 and stage1 will be supported?
>
> Additionally, I currently see numerous "breaking" changes transitioned via
> #[cfg(stage0)].  The assumption is that stage0 is older than the breaking
> change, and stage1+ is newer than the change.  Amongst other things, this
> means that you can't currently have the full compile-experience (using
> --enable-local-rust) using a compiler that you've just built :(
> I see there's already been discussion towards other mechanisms for tagging
> version-specific code(*).  I'm new to the rust mailing list and community,
> so mostly I'm just looking to get caught up on the conversations around this
> and register a vote for "we need to have a story around this for 1.0, and
> not later".
>
> (*)
> http://discuss.rust-lang.org/t/pre-rfc-rust-version-attribute-specifying-rust-language-version-within-source-code
>
>  - Gus
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>

Re: [rust-dev] stage0 in a post-rust-1.0 world

[Angus Lees]

[-- Attachment #1: Type: text/plain, Size: 4368 bytes --]

Yeah, I can appreciate that concern and I wouldn't want to do anything to
slow us down.  There are several additional aspects here however:

- I would expect developers anywhere to be happy to use Debian "testing",
which is a rolling release that should be able to keep a rust package that
only lags rust official releases by about 2 weeks.  It might be different
for rust core developers, but I suspect automatically pushing out rust
binary releases via apt-get update will actually lead to more rapid uptake
of new releases rather than waiting for everyone to fetch and build from
source.

- For building-rust-using-local-rust, the only necessary condition is that
the rust compiler *in unstable* is suitable to use as a stage0.  This means
effectively zero delay after rust releases - although there is some work
for me (or whomever) for each release and iterating the stage0 requirements
several times a week would be tiresome.

- Eventually there will be a program written in rust that is packaged up by
someone and makes it into a Debian "stable" release (mozilla?). For
supporting security fixes, etc, it is vital that that (possibly 2 years
old) rust source code can be patched and rebuilt.  The easiest way to make
this possible is to snapshot the rust compiler version current at the time
the program was written.  This is exactly what happens when a "stable"
release is cut that includes a rust compiler.
I can also forcibly *prevent* rust from appearing in any stable release
easily enough.  The downside of course is that no software written in rust
can go into a stable release either, so that seems like overkill.

In short: I don't see any technical conflicts between making a rust
compiler available in the Debian archive and rapid-iteration goals.  I'd be
happy to plaster "you want to ensure you have a recent version for new
development" warnings everywhere if that was the only remaining concern.

 - Gus

On Sun Dec 21 2014 at 6:36:06 PM Matthew McPherrin <mozilla@mcpherrin.ca>
wrote:

> I absolutely believe rust needs to give up its snapshots to be sanely
> and widely packaged, but when I mentioned this before, there didn't
> seem to be a lot of traction for the idea.
>
> In particular, the Rust team still plans to move much quicker than,
> say, Debian releases new packages.  In that way, distribution
> packaging is a negative:  Rust is far from "done", and having people
> using even three month old compilers is likely to be a bad idea.
>
>
> On Sat, Dec 20, 2014 at 11:29 PM, Angus Lees <gus@inodes.org> wrote:
> > I wanted to remember how to be a Debian Developer, and rust-1.0 is coming
> > up, so I thought it was time to look into how one might package up rust
> for
> > a distribution (yes, I'm aware a few other DDs have looked at this
> earlier;
> > I've read some of their wiki pages/code but no, I haven't contacted them
> > yet).
> >
> > Once rust is bootstrapped on a new distro/architecture, it would be nice
> to
> > be able to build a rust release using the regular rust compiler rather
> than
> > downloading a pre-built opaque stage0 blob.  How would this work in
> > practice?
> >
> > Specifically, once we reach 1.0:
> > - Will the rust stage1 source be limited to using "stable" rust language
> > features?
> > - What sort of version skew between stage0 and stage1 will be supported?
> >
> > Additionally, I currently see numerous "breaking" changes transitioned
> via
> > #[cfg(stage0)].  The assumption is that stage0 is older than the breaking
> > change, and stage1+ is newer than the change.  Amongst other things, this
> > means that you can't currently have the full compile-experience (using
> > --enable-local-rust) using a compiler that you've just built :(
> > I see there's already been discussion towards other mechanisms for
> tagging
> > version-specific code(*).  I'm new to the rust mailing list and
> community,
> > so mostly I'm just looking to get caught up on the conversations around
> this
> > and register a vote for "we need to have a story around this for 1.0, and
> > not later".
> >
> > (*)
> > http://discuss.rust-lang.org/t/pre-rfc-rust-version-attribut
> e-specifying-rust-language-version-within-source-code
> >
> >  - Gus
> >
> > _______________________________________________
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
>

[-- Attachment #2: Type: text/html, Size: 5486 bytes --]