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?
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Thu, 2018-02-15 at 18:35 -0800, Josh Stone 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?
Yes. I don't think there is better way of doing this.. Do we actually want to ship both versions of rustfmt just for users to be able to switch?
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.
Meh.. - -- - -Igor Gnatenko
On Fri, Feb 16, 2018 at 3:35 AM, Josh Stone jistone@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@lists.fedoraproject.org To unsubscribe send an email to rust-leave@lists.fedoraproject.org
On 02/15/2018 10:10 PM, Igor Gnatenko wrote:
Do we actually want to ship both versions of rustfmt just for users to be able to switch?
I don't think that's necessary. The "preview" version really is the newer release of the old codebase, despite what the numbers say.
On 02/16/2018 01:57 AM, Fabio Valentini wrote:
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).
I do think it's valuable to package now, because it really is improved over the old version. I think an epoch is not so horrible, but I do understand the general distaste.
We could take upstream's lead and call this subpackage rustfmt-preview instead, so it's distinct from the existing rustfmt.rpm. They'll be providing conflicting files in %{_bindir} though.
Is there a way to make "dnf install /usr/bin/rustfmt" prefer the preview package? Can Provides+Obsoletes make that work?
On 02/16/2018 03:35 AM, Josh Stone wrote:
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?
What's the value of having a rustfmt subpackage?
Could you just obsolete the rustfmt package with the rust package and ship the program there?
Thanks, Florian
On 02/19/2018 03:30 AM, Florian Weimer wrote:
On 02/16/2018 03:35 AM, Josh Stone wrote:
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?
What's the value of having a rustfmt subpackage?
Could you just obsolete the rustfmt package with the rust package and ship the program there?
Perhaps, but it also comes with a cargo-fmt binary that ought to require the cargo package, and I don't really want that circular dependency.
On 02/19/2018 08:09 PM, Josh Stone wrote:
Could you just obsolete the rustfmt package with the rust package and ship the program there?
Perhaps, but it also comes with a cargo-fmt binary that ought to require the cargo package, and I don't really want that circular dependency.
Hmm. You could put that binary in its own package (say cargo-fmt).
Is cargo-fmt supposed to be called directly, or used by cargo to implement the reformatting? It looks like the dependency should go in the other direction …
Thanks, Florian
On 02/19/2018 01:29 PM, Florian Weimer wrote:
On 02/19/2018 08:09 PM, Josh Stone wrote:
Could you just obsolete the rustfmt package with the rust package and ship the program there?
Perhaps, but it also comes with a cargo-fmt binary that ought to require the cargo package, and I don't really want that circular dependency.
Hmm. You could put that binary in its own package (say cargo-fmt).
Is cargo-fmt supposed to be called directly, or used by cargo to implement the reformatting? It looks like the dependency should go in the other direction …
You're supposed to run this as "cargo fmt", which invokes cargo-fmt. That's not a cargo dependency though, as it will do this for *any* "cargo foo" subcommand it doesn't recognize, much like git does.
cargo-fmt will invoke "cargo metadata" to get the file list, which makes this a real dependency from cargo-fmt to cargo.
On 02/19/2018 10:45 PM, Josh Stone wrote:
On 02/19/2018 01:29 PM, Florian Weimer wrote:
On 02/19/2018 08:09 PM, Josh Stone wrote:
Could you just obsolete the rustfmt package with the rust package and ship the program there?
Perhaps, but it also comes with a cargo-fmt binary that ought to require the cargo package, and I don't really want that circular dependency.
Hmm. You could put that binary in its own package (say cargo-fmt).
Is cargo-fmt supposed to be called directly, or used by cargo to implement the reformatting? It looks like the dependency should go in the other direction …
You're supposed to run this as "cargo fmt", which invokes cargo-fmt. That's not a cargo dependency though, as it will do this for *any* "cargo foo" subcommand it doesn't recognize, much like git does.
cargo-fmt will invoke "cargo metadata" to get the file list, which makes this a real dependency from cargo-fmt to cargo.
Okay, so create a subpackage for it, with
Requires: cargo Supplements: cargo
in it? That would avoid the epoch and defang the dependency loop a bit.
The main rust package would still obsolete rustfmt.
Thanks, Florian