replacement of openssl with libressl with a overlay results in evaluation failures

[qolii]

Issue description

Something changed recently, breaking the libressl derivation.

Steps to reproduce

I globally override openssl with libressl using

packageOverrides = pkgs: rec {
  openssl = pkgs.libressl_2_8.override { fetchurl = pkgs.stdenv.fetchurlBoot; };
};

This usually works, but something must have changed, because I now see the error:

error: anonymous function at /nix/nixpkgs/pkgs/development/libraries/libressl/default.nix:1:1 called with unexpected argument 'buildPackages', at /nix/nixpkgs/lib/customisation.nix:124:63
(use '--show-trace' to show detailed location information)

Naively adding buildPackages to the libressl derivation's arguments set then yields:

error: anonymous function at /nix/nixpkgs/pkgs/development/libraries/libressl/default.nix:1:1 called with unexpected argument 'perl', at /nix/nixpkgs/lib/customisation.nix:124:63
(use '--show-trace' to show detailed location information)
building the system configuration...

And finally, adding perl makes everything build correctly.

I'm happy to submit a PR with this fix (or one just adding ... instead of these named inputs), but it doesn't seem very neat to do that. Is there a better way?

[qolii]

As maintainers: @thoughtpolice, @fpletz, @globin

[infinisil]

Caused by this

nixpkgs/pkgs/top-level/all-packages.nix

Lines 260 to 263 in 01ad172

	openssl = buildPackages.openssl.override {
	fetchurl = stdenv.fetchurlBoot;
	inherit perl;
	buildPackages = { inherit perl; };

which is done since a1fec86, #56067, ping @oxij

I'm not sure if there's a nice to way solve this

[oxij]

Yes, that is a bad interaction with #56067. I see the following possible solutions: - generalize `fetchurl` into a function that would take "overriden-`openssl`-generator" as an argument, it will be very ugly, - check `openssl` package name in `fetchurl` expression and override it differently for `libressl`, okay-ish, I guess, - use `overrideWithScope` of #44196 in `fetchurl` to override to `openssl`, merging #44196 will bloat allocations metric even more, AFAICS, so I'd consider this way to be undesirable from performance standpoint, - use `extraScope` of #56227 to just set `openssl = libressl` in `extraScope`, `fetchurl` will use `openssl`, the rest will work via `libressl` as expected, simple, but does not give the ideal result, - make it a use-flag of #56227, replacing `openssl` with `libressl` is a common enough thing to have an option for this and properly implement it declaratively, IMHO, the best way IMHO, but it needs #56227 to be merged, and it doesn't seem likely it would to be merged soon, if at all, - revert #56067, architecturally undesirable.

[qolii]

@oxij, while I am super intrigued by your proposal in #56227 (and to quote your own self, If stuff like this isn't cool, then I don't know what is!), would adding an ellipsis to libressl's args list be completely unacceptable? That fix is nice and tiny. And AFAICT, this problem is quite specific to the way you have configured fetchurl in all-packages.nix. Or is this a pattern?

Alternatively, in the same way that using a global libressl override, at least until #56067, had a "surprise" extra requirement that you apply it like:

openssl = pkgs.libressl_2_8.override { fetchurl = pkgs.stdenv.fetchurlBoot; };

could we simply note that to make this work, you need to also add an additional override to fetchurl itself to "put back" your changes from #56067 (I think this would be possible, right? Although a little fiddly).

Then, when a real solution comes along, we could adopt it.

[oxij]

@oxij, while I am super intrigued by your proposal in #56227 (and to quote your own self, *If stuff like this isn't cool, then I don't know what is*!), would adding an ellipsis to `libressl`'s args list be completely unacceptable? That fix is nice and tiny.

Yes, adding an ellipsis or fake arguments to `libressl` with a comment explaining the purposes would be okay, IMO, but I feel like checking derivation name is a cleaner solution for the current nixpkgs, it can also be straightforwardly adapted to use-flags later.

[qolii]

Quickly finding through nixpkgs, I see we also have wolfssl and boringssl. I don't know if those are meant to be global replacements for OpenSSL the same way LibresSSL is, but if so, would we need to special-case both of them too?

Although, since it hasn't come up yet, maybe nobody needs this at the moment and we can wait for a more comprehensive solution.

[stale]

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

[matthewbauer]

Still important

[bqv]

Still important

[stale]

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

[maybebyte]

Still important.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-can-i-override-openssl/47367/1