Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Unstable Rust Packaging? #8697

Closed
Havvy opened this issue Jul 8, 2015 · 8 comments
Closed

Remove Unstable Rust Packaging? #8697

Havvy opened this issue Jul 8, 2015 · 8 comments

Comments

@Havvy
Copy link
Contributor

Havvy commented Jul 8, 2015

I'm opening an issue here to ask whether this would be a good idea.

Those who do want unstable Rust packages have another way of doing so. I'll let @eddyb explain how if he wants to.

But the current dev version is pre-1.0.0, and I don't see anybody wanting to update it. To keep the package repository slim, I'd like to remove them.

Does anybody have a problem with this? Those who are core maintainers, can you say that you don't have a problem with this?

@eddyb
Copy link
Contributor

eddyb commented Jul 8, 2015

@Ericson2314 and @Tobba have a working solution that uses the upstream nightlies and is parametrized by a nightly date and a hash of the downloaded archive.

@Ericson2314
Copy link
Member

Yeah IMO nixpkgs need only have stable, or maybe beta. No need for nightly/HEAD source builds unless we get a critical mass rustc developers using nixos (I'm sure @eddy can fend for himself :D).

I'm not sure our script belongs in it as downloading binaries is gross, but to compensate I made https://nixos.org/wiki/Rust so people have a way to discover it. I suppose whatever you do, good to document it too on that that page?

@jagajaga
Copy link
Member

jagajaga commented Jul 8, 2015

👍 to left only stable version.

@wizeman
Copy link
Member

wizeman commented Jul 9, 2015

I am opposed to removing the unstable Rust packaging.

I use unstable Rust frequently because it's the only way to use certain useful features such as compiler plugins (e.g. all of the lints in rust-clippy require unstable Rust).

I don't find it to be a big burden to keep the unstable Rust compiler updated, since much of the Nix packaging is already shared between the stable and the unstable Rust compilers.

In fact, I already have a patch ready to update unstable Rust to a more recently nightly, but I'm waiting for #8668 to be merged first. I also have a python script that can update unstable Rust to the latest nightly (in fact, to exactly the same commit that the latest nightly has been built from).

I much prefer using this script and compiling from source than downloading and running random binaries from the Internet. Each binary that you download and run increases the chance that your machine is trojaned due to the downloading server having been compromised. It is much harder to trojan a git repository without it being quickly noticed by someone.

@Ericson2314
Copy link
Member

@wizeman if you want to maintain Nightly, I see no problem with that. Just not sure if anybody else does :).

@wizeman
Copy link
Member

wizeman commented Jul 9, 2015

@Ericson2314 No problem, I'll be happy to do it!

@Havvy
Copy link
Contributor Author

Havvy commented Jul 12, 2015

Alright, you have a script that builds from source instead of downloading a binary. This still has to be updated every day to maintain freshness. Given that there's at least a week before the unstable branch updates (and lately it's been more like a month), and the fact that stable releases of nixpkgs are once every couple months, is there a place for daily changing packages in nixpkgs? Is there a reason it has to be in nixpkgs and not as part of some other nix repo?

But this issue is closed by nature of @wizeman being willing to maintain the nightly packages. My questions are more questions of policy. As such, I'm closing this issue.

@Havvy Havvy closed this as completed Jul 12, 2015
@Ericson2314
Copy link
Member

Who updates GHC head?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants