On Fri, Feb 16, 2018 at 3:35 AM, Josh Stone <jistone(a)redhat.com> wrote:
I'm updating to 1.24:
https://blog.rust-lang.org/2018/02/15/Rust-1.24.html
One of the headline features is that it's now shipping rustfmt along
with the rust distribution. (Although technically, the component is
still called rustfmt-preview.)
This differs from the rustfmt we already have packaged in Fedora,
because they've now embraced the use of internal rustc libraries.
That's OK when it's shipped along with rustc-src, but it means we really
need to package it all together too, so it's one ABI-compatible build.
The other awkwardness is that they reset the version when they branched
to this "rustfmt-nightly" style. So the old version we have packaged is
rustfmt 0.9, but the current version of the new binary is 0.3.4.
So, I think what I can do is have a subpackage of the rust.srpm, with
its own name, version, *and* epoch to supersede the old package.
Name: rust
Version: 1.24.0
%package -n rustfmt
Version: 0.3.4
Epoch: 1
Does that work? Is there a better way to handle this?
From reading the release notes, the new rustfmt is explicitly in a
tech preview state.
Is there a benefit in going through the epoch and versioning limbo
just to get this preview into fedora, while the old rustfmt is still
(and will continue to be) available?
I'd just wait until the new one is considered stable, at which point
no epoch bump would be needed (Version should be 1.0 at that point,
according to the rust blog post).
Just my 2c. (or 3).
Fabio
> Note, in the near future this is also how rls and clippy will be
> released. And technically, cargo already gets shipped in rustc-src too,
> but it doesn't use unstable features, so that should be fine for us to
> continue packaging on its own.
> _______________________________________________
> Rust mailing list -- rust(a)lists.fedoraproject.org
> To unsubscribe send an email to rust-leave(a)lists.fedoraproject.org