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(a)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-ef...
>>
>> - (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...
>> - (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...
>>
>> - (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...
>> - (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...
>>
>> - (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