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

Come up with a good solution to hydra of free things with unfree intermediate dependencies #41

Open
copumpkin opened this issue Jan 27, 2015 · 6 comments

Comments

@copumpkin
Copy link
Owner

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?

@shlevy
Copy link
Collaborator

shlevy commented Feb 20, 2015

@edolstra @rbvermaa feedback please? I can implement something for hydra to only distribute the non-proprietary products, but would rather know whether it would be acceptable for hydra.nixos.org (and something similar for cache.nixos.org) first.

@copumpkin
Copy link
Owner Author

Just to further justify why I want this:

  • node.js, for example, depends on apple-sdk (unfree headers) to build the basic toolchain. This means no node.js packages can ever live in the binary cache for darwin
  • emacs has a Carbon (unfree) dependency on darwin
  • vim has a CoreServices (unfree) dependency on darwin (for pasteboard stuff, which people actually use apparently)
  • svn needs some unfree stuff to integrate properly with the keychain
  • I'd like to start packaging Mac apps, and they'll all need at least Cocoa (unfree)
  • It would greatly simplify my life and allow me to improve stability if I could copy the couple of remaining fundamental impurities (parts of libSystem, various apple frameworks) into the store and relink them to our free things (using install_name_tool or similar). We've had some very elusive bugs due to the combination of pure and impure versions of the same thing that this feature would virtually eliminate.
  • loads more packages want to use apple frameworks where possible: doxygen, check, mercurial, probably a bunch more we haven't found yet

@edolstra
Copy link

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 unfree-system-library).

@shlevy
Copy link
Collaborator

shlevy commented Feb 20, 2015

hydra can keep track per store path though, right?

@shlevy
Copy link
Collaborator

shlevy commented Feb 20, 2015

Also, assuming you don't want to modify the nix database what do you think of mkDerivation creating a meta output with a serialization of meta if it's set?

@edolstra
Copy link

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 unfree to $out/nix-support/license, or something like that. Then hydra-server can just check the contents of that file, if it exists.

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

3 participants