rustup is used to *download official / beta / nightly toolchains from the internet*, so having to download rustup itself as well isn't that bad, I think.

Official rust builds are signed and rustup does verify the signature: https://github.com/rust-lang/rustup/blob/master/src/dist/download.rs#L167. Having rustup packaged would create a chain of trust from Fedora's official repo to the downloaded toolchain. In any case, tt's more convenient to the users if they can get it directly from a package manager.

Additionally, running curl | bash does additional setup steps, like setting up $PATH for rustup to work correctly. How do you expect to handle that with a package?

That's a good point, though the script doesn't actually do any setup, rustup does them by itself if it's invoked with argv[0]=="rustup-init". We could leave the packaged binary as rustup-init (that's the target binary name in upstream), though this might not be very intuitive to users as they could be expecting the command rustup being available straight away; or we could patch rustup such that it always behaves like rustup-init if placed under /usr/bin, and behaves normally elsewhere (after being copied to user's home), but this might be too hacky...

Please mention that the pending update is blocking rustup in the respective bugs, like this one for enum-map:

Will do.

If there's an update to an incompatible version (like 1 -> 2 in this case), then there's two choices:

Yeah that's basically what I expected. Is there a way to reliably search for reverse dependencies? https://pkgs.org/search/?q=rust-enum-map provides a "Required By" search button and it doesn't seem like enum-map has any dependents, but I don't know if this is complete.

Thanks a lot for the help! I'll be there for the event.

Andy

On 03/08/2022 08:51, Fabio Valentini wrote:

On Wed, Aug 3, 2022 at 1:36 AM Andy Wang cbeuw.andy@gmail.com wrote:

...

Hi Rust SIG,

Welcome!

...

I'm trying to package rustup so that users won't have to curl | bash. Here are the dependency issues, and my attempts to solve them:

I'm wondering what's your target audience here? rustup is used to *download official / beta / nightly toolchains from the internet*, so having to download rustup itself as well isn't that bad, I think. Additionally, running curl | bash does additional setup steps, like setting up $PATH for rustup to work correctly. How do you expect to handle that with a package?

...

• (crate(effective-limits/default) >= 0.5.3 with crate(effective-limits/default) < 0.6.0~)

On COPR: https://copr.fedorainfracloud.org/coprs/cbeuw/rustup-deps/package/rust-effec...

• (crate(enum-map/default) >= 2.0.3 with crate(enum-map/default) < 3.0.0~)

Package exists but on version 1.1.0: https://src.fedoraproject.org/rpms/rust-enum-map

• (crate(git-testament/default) >= 0.2.0 with crate(git-testament/default) < 0.3.0~)

Missing subdependencies:

• (crate(no-std-compat/alloc) >= 0.4.0 with crate(no-std-compat/alloc) < 0.5.0~)
  

On COPR https://copr.fedorainfracloud.org/coprs/cbeuw/rustup-deps/package/rust-no-st...

• (crate(no-std-compat/default) >= 0.4.0 with crate(no-std-compat/default) < 0.5.0~)
  

On COPR https://copr.fedorainfracloud.org/coprs/cbeuw/rustup-deps/package/rust-no-st...

• (crate(rs_tracing/default) >= 1.0.1 with crate(rs_tracing/default) < 2.0.0~)

On COPR https://copr.fedorainfracloud.org/coprs/cbeuw/rustup-deps/package/rust-rs_tr...

• (crate(rs_tracing/rs_tracing) >= 1.0.1 with crate(rs_tracing/rs_tracing) < 2.0.0~)

On COPR https://copr.fedorainfracloud.org/coprs/cbeuw/rustup-deps/package/rust-rs_tr...

• (crate(sequoia-openpgp/crypto-rust) >= 1.5.0 with crate(sequoia-openpgp/crypto-rust) < 2.0.0~)

Package exists but missing crypto-rust feature, PR filed https://src.fedoraproject.org/rpms/rust-sequoia-openpgp/pull-request/1

• (crate(zstd/default) >= 0.11.0 with crate(zstd/default) < 0.12.0~)

Package exists but on version 0.10.0 https://src.fedoraproject.org/rpms/rust-zstd

I can help with updating the dependencies that are already packaged, but not at the correct version. Please mention that the pending update is blocking rustup in the respective bugs, like this one for enum-map: https://bugzilla.redhat.com/show_bug.cgi?id=2009715

That will put them at the top of my TODO list.

...

I have several questions:

1. How can I tell fedpkg to use my COPR project so that git-testament can be built? Or can it only be packaged after its dependency no-std-compat is in the official repo?

You can't. fedpkg is the wrong tool for this stage of package development. You can, however, use the "correct" tools and tell them to use packages built in your COPR:

• generate a mock cfg with "copr-cli mock-cfg name-of-your-copr

name-of-the-chroot > rustup.cfg"

• tell mock to use this configuration when building packages with

"mock -r rustup.cfg ./path-to-rustup.src.rpm"

...

2. What should we do with enum-map, which requires a backwards-incompatible major version update. I can't find policy documents on this

This is not a special case for Rust packages, which is why it's not documented in the Rust packaging guidelines. If there's an update to an incompatible version (like 1 -> 2 in this case), then there's two choices:

• port all users of version 1 to version 2, update to version 2
• package both version 1 and version 2 in parallel

Which path you take depends on the number of packages that are not yet compatible with version 2, and how difficult porting to the new version would be.

...

3. I've never submitted a Fedora package before, so would anyone in Rust SIG be willing to sponsor me when I create my Review Request?

I too have the powers to sponsor new packagers, though I currently don't have the time to guide you through this process. As mentioned by mulhern, I'll be talking about Rust packaging at the Rust Packaging Workshop on Friday, at Nest. If you cannot attend, the talks and workshops are all recorded and uploaded to YouTube.

Fabio

On Wed, Aug 3, 2022 at 12:03 PM Andy Wang cbeuw.andy@gmail.com wrote:

...

rustup is used to *download official / beta / nightly toolchains from the internet*, so having to download rustup itself as well isn't that bad, I think.

Official rust builds are signed and rustup does verify the signature: https://github.com/rust-lang/rustup/blob/master/src/dist/download.rs#L167. Having rustup packaged would create a chain of trust from Fedora's official repo to the downloaded toolchain. In any case, tt's more convenient to the users if they can get it directly from a package manager.

You can also get the toolchain itself from Fedora though, which we keep up-to-date with every stable upstream release on all active Fedora releases. There's only a small delay due to the bodhi update process, about a week. (Or less if people give karma!)

Maybe you still want rustup for beta/nightly toolchains, or for trying code with even older toolchains. I just want to make sure that for the *stable* Rust toolchain, we're setting the expectation that Fedora's own toolchain packages should work well.

Thanks, Josh