openvswitch: fix cross-compilation

[nspin]

openvswitch depends on both build and host openssl. Both must be overridden in all-packages.nix. I propose the following:

openvswitch = callPackage ../os-specific/linux/openvswitch {   
  openssl = __splicedPackages.openssl_1_0_2;
};

However, __splicedPackages is not used in this way anywhere else in nixpkgs.

A discussion of this sort of case can be found here: #49526 (comment).

Motivation for this change

Fixes cross-compilation for openvswitch.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

Notify maintainers

cc @

[matthewbauer]

/cc @Ericson2314

[Mic92]

Is __splicedPackages targetPackages?

[Mic92]

Or in other words, what does this change fixes?

[nspin]

openssl_1_0_2 is just a derivation, whereas __splicedPackages.openssl_1_0_2 is augmented with attributes referring to that derivation for other (host, target) pairs. For example, __splicedPackages.openssl_1_0_2.nativeDrv refers to buildPackages.openssl_1_0_2.

See this comment for more detail: #68967 (comment)

[nspin]

openvswitch/default.nix refers to openssl in both .nativeBuildInputs and .buildInputs. In the case of cross-compilation, mkDerivation accesses spliced attributes for elements of these lists. So, the openssl argument to openvswitch/default.nix must be spliced.

callPackage automatically uses spliced packages. However, the packages in scope in top-level/all-packages.nix are not spliced. So, to pass in a spliced openssl_1_0_2, we must explicitly refer to __splicedPackages.openssl_1_0_2.

This may not be the best solution to cross-compiling this particular package, but similar situations appear throughout Nixpkgs. I think it's worth considering how we should be handling them.

[Mic92]

Ok. @Ericson2314 seems to prefer buildPackages though.

[nspin]

I agree with them. This case is a bit more complicated because openvswitch really takes two distinct openssl derivations as parameters, one for the build and one to link against, which are different in the case of cross compilation. They suggest what seems like the most sensible solution right now: #68900 (comment). That is, to explicitly allow the overriding of both derivations separately.

[stale]

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

[nspin]

(In response to the automatic marking of this PR as stale)

I'm still interested in how cross compilations issues like this one, brought about as a side effect of splicing, are best addressed.

See also #68900

[Ericson2314]

Sorry I missed this for the better part of a year 😱!

It's a clever fix, but I am wary of using splicing explicitly like this as it's such an ugly mechanism with so many problems. Can you rewrite this with an explicit buildPackages.openssl?

[Mic92]

Do you have a good solution on how to deal with overrides in all-packages.nix or should we make all overrides there explicit?

[Ericson2314]

Yes, I think it is just better to make them explicit for now. #58327 did not work to well as it caused a bunch of infinite recursion. This will be more verbose, but ultimately easier to debug I think, and we can point to the the verbosity after the fact as evidence if someone is trying to overhaul callPackage and friends.

[stale]

I marked this as stale due to inactivity. → More info