-
Notifications
You must be signed in to change notification settings - Fork 1
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
Come up with a good solution to hydra of free things with unfree intermediate dependencies #41
Comments
Just to further justify why I want this:
|
I don't see how this could be implemented easily, since Nix doesn't keep track of licenses per store path. So Hydra can't look at the closure of a path and see if it contains unfree packages. It's also debatable whether a free software distribution like Nixpkgs should depend on unfree packages, but I guess it's okay for system libraries (even the GPL makes an exception for that). We should probably introduce a separate license type for that though (like |
hydra can keep track per store path though, right? |
Also, assuming you don't want to modify the nix database what do you think of mkDerivation creating a |
Making Hydra keep track of store paths (and thereby duplicating the Nix database) doesn't seem very nice. It would be easier and more reliable to store the license in the Nix db. However, that would require making .drvs include meta.license. Another possibility (I think somebody suggested this before): have unfree packages write |
For example,
vim
uses Mac-specific code to integrate with the Mac clipboard. The code in question requires Apple's SDK bundle of headers, which is considered (I think?) unfree. This means that we have a free program (and there will be many others) that depends on something unfree. That's normally fine, except for the fact that Hydra refuses to build anything unfree or that depends on unfree things, so that makes a big swath of the Apple ecosystem uncacheable. This is made worse by many "unixy" projects having special codepaths in their autoconf that turn on Mac-specific features, so even things that don't appear Mac-specific in linux-land might end up falling under this category.@shlevy @rbvermaa @edolstra @joelteon any ideas?
The text was updated successfully, but these errors were encountered: