3 ms·

Do you think it would be reasonable to package rustup in the Fedora repos? I ask because for a development machine, it makes more sense to be able to install mu

Do you think it would be reasonable to package rustup in the Fedora repos? I ask because for a development machine, it makes more sense to be able to install multiple toolchains in parallel.

snuxoll 10y ago
In the repos directly? No, probably not. rbenv and pyenv aren't in the repos either, I'm not aware of any specific policy against it but it introduces some hesitance to provide software in the repos that can be used to then install software that may conflict with software managed by the package manager itself. rubygems, setuptools/pip and cargo as examples only typically handle installation of libraries and are generally "well behaved" citizens that put files in specific locations and don't install or manage new versions of the underlying language runtime, meanwhile rbenv/pyenv/rustup can mess with your path and potentially cause conflicts that could end up with people filing bugs that are closed "not our problem, we support this one specific environment that's in the repos". Someone is welcome to try, feel free to open a thread on the fedora-devel mailing list and see what anyone else thinks. But even if rustup doesn't make it into the official repos I don't see why someone couldn't put it up on COPR.
- tmzt 10y ago
  Could rustup use PackageKit/yum/dnf to do this on Fedora? It would be really nice to be able to point to one command in the documentation that would work whether installed directly by the developer or provided by a distro. Debian specifically provides it's own alternatives system to handle symlinks in a global manner, but nothing for directory-specific ones. I'm not sure about Fedora. With `rustup` replacing `multirust`, it would be useful to point to a common command that in turn would call the distro-provided facility for global links. Also, congratulations on 1.10! Looking forward to servo.apk in the coming weeks as well.
snuxoll 10y ago
As an addendum, there's nothing preventing anyone from packaging multiple versions of Rust assuming it properly supports it (for example installing to /usr/bin as rustc1.10, then we can symlink /usr/bin/rustc to the most recent one) - and if Rust releases a 2.0 at some point it is likely that there will be multiple versions available for a release or two while programs are modified to be compatible with the newer release. However, as Rust is fairly commited to semver I don't see much use in this UNTIL there is a new major release.

Do you think it would be reasonable to package rustup in the Fedora repos? I ask because for a development machine, it makes more sense to be able to install multiple toolchains in parallel.

snuxoll 10y ago

In the repos directly? No, probably not. rbenv and pyenv aren't in the repos either, I'm not aware of any specific policy against it but it introduces some hesitance to provide software in the repos that can be used to then install software that may conflict with software managed by the package manager itself. rubygems, setuptools/pip and cargo as examples only typically handle installation of libraries and are generally "well behaved" citizens that put files in specific locations and don't install or manage new versions of the underlying language runtime, meanwhile rbenv/pyenv/rustup can mess with your path and potentially cause conflicts that could end up with people filing bugs that are closed "not our problem, we support this one specific environment that's in the repos". Someone is welcome to try, feel free to open a thread on the fedora-devel mailing list and see what anyone else thinks. But even if rustup doesn't make it into the official repos I don't see why someone couldn't put it up on COPR.

tmzt 10y ago
Could rustup use PackageKit/yum/dnf to do this on Fedora? It would be really nice to be able to point to one command in the documentation that would work whether installed directly by the developer or provided by a distro. Debian specifically provides it's own alternatives system to handle symlinks in a global manner, but nothing for directory-specific ones. I'm not sure about Fedora. With `rustup` replacing `multirust`, it would be useful to point to a common command that in turn would call the distro-provided facility for global links. Also, congratulations on 1.10! Looking forward to servo.apk in the coming weeks as well.

snuxoll 10y ago

As an addendum, there's nothing preventing anyone from packaging multiple versions of Rust assuming it properly supports it (for example installing to /usr/bin as rustc1.10, then we can symlink /usr/bin/rustc to the most recent one) - and if Rust releases a 2.0 at some point it is likely that there will be multiple versions available for a release or two while programs are modified to be compatible with the newer release. However, as Rust is fairly commited to semver I don't see much use in this UNTIL there is a new major release.