No require file

[shlevy]

According to @edolstra's comments on #2129, requireFile should not be used in nixpkgs. Merging this should wait for after 14.04 as it removes some key packages.

[edolstra]

Though I would be much in favor of this, in particular the removal of oraclejdk is going to make some people unhappy...

We may want to consider creating a separate repository for these (say, "nix-warez").

[shlevy]

+1 for that. Do you think it makes sense to put broken or WIP stuff in the same repo? I think a repo for "stuff with no expectation of anything working or being the right thing but still might be useful to share" in general would be nice.

[offlinehacker]

What's wrong with requireFile? I don't see removing packages as solution, i
use some of this things in production.
On Apr 7, 2014 4:58 PM, "Shea Levy" notifications@github.com wrote:

+1 for that. Do you think it makes sense to put broken or WIP stuff in the
same repo? I think a repo for "stuff with no expectation of anything
working or being the right thing but still might be useful to share" in
general would be nice.

Reply to this email directly or view it on GitHubhttps://github.com//pull/2160#issuecomment-39740614
.

[offlinehacker]

So if i pass correct parameters to curl and hack the download of unfree
package without requireFile, then it's ok?
On Apr 7, 2014 5:03 PM, "Jaka Hudoklin" jakahudoklin@gmail.com wrote:

What's wrong with requireFile? I don't see removing packages as solution,
i use some of this things in production.
On Apr 7, 2014 4:58 PM, "Shea Levy" notifications@github.com wrote:

+1 for that. Do you think it makes sense to put broken or WIP stuff in
the same repo? I think a repo for "stuff with no expectation of anything
working or being the right thing but still might be useful to share" in
general would be nice.

Reply to this email directly or view it on GitHubhttps://github.com//pull/2160#issuecomment-39740614
.

[offlinehacker]

Also by removing cgminer we break nixos module we have.
On Apr 7, 2014 5:05 PM, "Jaka Hudoklin" jakahudoklin@gmail.com wrote:

So if i pass correct parameters to curl and hack the download of unfree
package without requireFile, then it's ok?
On Apr 7, 2014 5:03 PM, "Jaka Hudoklin" jakahudoklin@gmail.com wrote:

What's wrong with requireFile? I don't see removing packages as solution,
i use some of this things in production.
On Apr 7, 2014 4:58 PM, "Shea Levy" notifications@github.com wrote:

+1 for that. Do you think it makes sense to put broken or WIP stuff in
the same repo? I think a repo for "stuff with no expectation of anything
working or being the right thing but still might be useful to share" in
general would be nice.

Reply to this email directly or view it on GitHubhttps://github.com//pull/2160#issuecomment-39740614
.

[shlevy]

The cgminer commit removed the module.

@edolstra can speak better than I to the policy, but the point is not specifically about requireFile but rather about undistributable proprietary source inputs I believe.

[offlinehacker]

Cgimer is opensource, just amdapp-sdk isn't and it also builds without it.
So correct fixes would be nice not just removing stuff. Also migration
strategy would be nice to have. Nix files are just build instructions, i
don't see where's the problem.
On Apr 7, 2014 5:24 PM, "Shea Levy" notifications@github.com wrote:

The cgminer commit removed the module.

@edolstra https://github.com/edolstra can speak better than I to the
policy, but the point is not specifically about requireFile but rather
about undistributable proprietary source inputs I believe.

Reply to this email directly or view it on GitHubhttps://github.com//pull/2160#issuecomment-39744148
.

[edolstra]

No, it mostly is about requireFile. The use of requireFile makes it impossible to install a package (and by extension, a NixOS module that depends on it) automatically. Since the point of a package manager is to automate installation, that's a big problem. Essentially, if a package shows up in "nix-env -qa", users should be able to expect that "nix-env -i" installs it without further intervention.

However, if we hide unfree packages by default (#2134), this becomes less of an issue, since then the user explicit has to ask for it.

[shlevy]

Oh, OK. So if we had #2134 we could continue using requireFile?

[shlevy]

@offlinehacker I didn't know about cgminer, if @edolstra still wants this after #2134 I'll fix it to just not depend on amdapp-sdk

[offlinehacker]

Ok i guess hiding unfree packages kinda makes sense. The problem is that
you have unfree packages that can be auto installed(like ati_unfree).
On Apr 7, 2014 5:32 PM, "Eelco Dolstra" notifications@github.com wrote:

No, it mostly is about requireFile. The use of requireFile makes it
impossible to install a package (and by extension, a NixOS module that
depends on it) automatically. Since the point of a package manager is to
automate installation, that's a big problem. Essentially, if a package
shows up in "nix-env -qa", users should be able to expect that "nix-env -i"
installs it without further intervention.

However, if we hide unfree packages by default (#2134#2134),
this becomes less of an issue, since then the user explicit has to ask for
it.

Reply to this email directly or view it on GitHubhttps://github.com//pull/2160#issuecomment-39745206
.

[offlinehacker]

@shlevy thanks :)
On Apr 7, 2014 5:38 PM, "Shea Levy" notifications@github.com wrote:

@offlinehacker https://github.com/offlinehacker I didn't know about
cgminer, if @edolstra https://github.com/edolstra still wants this
after #2134 #2134 I'll fix it to
just not depend on amdapp-sdk

Reply to this email directly or view it on GitHubhttps://github.com//pull/2160#issuecomment-39745967
.

[bjornfor]

-1. Removing requireFile and all software (required) to use it is not nice to our users (and that includes me).

I hope we instead can set allowUnfree = false (like @edolstra suggests in #2134) to filter out these packages for people that don't want (to see) them. And still use requireFile when there is not other option.

@shlevy: A repo for "stuff with no expectation of anything working or being the right thing but still might be useful to share" sounds like a contradiction to me ;-)

[shlevy]

@bjornfor Currently in nixpkgs we have works in progress, experiments, completely broken packages... More than we can hope to maintain with our current community. Of course we could just nuke them, but having them somewhere where people can refer to them if/when they have time without them polluting nixpkgs seems like an improvement, no?

[peti]

The FlashTool utility can be dropped from Nixpkgs. In its current state, the expression is not particularly useful, and I've lost interest in investing more time into that subject because I don't need FlashTool any more.

[bjornfor]

@shlevy: I guess it's difficult to discuss this further while keeping it generic and not discussing specific packages / code. My personal opinion is still that a central repo for "work-in-progress, experiments, completely broken packages" is of little use and is better handled with traditional cooperation via git/github/mailing list (which does not require a central repo).

But I don't really mind if such an experimental repo existed (I don't have to use it). What I mainly reacted to is the idea of moving all packages using requireFile out of nixpkgs and into a separate repo, because that'd make my life more difficult. Fortunately, it seems I don't have to worry about that[1].

If there are specific packages or experiments you would like to get rid of (slowing down your nixpkgs hacking), please send pull-requests for removal and let the nixos community decide.

Btw, I'm curious of what specific things you would like to remove. Right now I can only think of broken packages, for which meta.broken = true seems like a good solution. Or?

[1] http://lists.science.uu.nl/pipermail/nix-dev/2014-April/012916.html

[jcumming]

I'm not particularly fond of requireFile. It tends to break builds a lot.

Is there a better way to support the use models of:

• I bought some software, and I'd like it to run on NixOS?
• I had to agree to a special license for this software, and I'd like it to run on NixOS?
• I'm using nix to stitch together a complex project that has binary blobs?

... and it should be possible to fix uqm. Hrm.

[shlevy]

@edolstra Closing this under the assumption that the disabling of unfree by default means it's OK to add more requireFile packages to nixpkgs.