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

https://discourse.nixos.org/t/how-to-distinguish-pkgsmusl-and-pkgsstatic/8745/5

CC @matthewbauer

So far, we've just been overriding individual packages in the overlay. I agree this is rather unsystematic, basically taking on the constraints of a downstream project despite living in the Nixpkgs proper.

That said, we don't add arbitrary configuration to the top-level like this. We would instead probably want to put something in stdenv.*Platform. Take a look at lib/systems/* for how that might be accomplished.

And... the best practice is (generally) as follows?

• don't build both static and dynamic (in a single build)
• default to dynamic
• use parameter called static to switch (some others have been used)

@Ericson2314 What about this, updated version of patch?

$ nix repl ~/deve/nixpkgs
nix-repl> stdenv.targetPlatform.isStatic
false
nix-repl> pkgsMusl.stdenv.targetPlatform.isStatic
false
nix-repl> pkgsStatic.stdenv.targetPlatform.isStatic
true

This way, to add something specific to static build, change will be only in one place -- in derivation itself, without need to keep list in pkgs/top-level/static.nix. It will help out-of-tree derivations, too.

And packages would be written like this?

{ stdenv, foo, bar
, static ? stdenv.targetPlatform.isStatic
}:

(So that they can be configured "individually" as well, though I expect most use cases will be fully static builds anyway.)

Not sure about this. If you keep static flag, it means that you can request static build with otherwise dynamic stdenv, which may or may not work (most likely not work, since glibc networking code can't be compiled statically, as I recall), but also it means that you can request dynamic build with static stdenv, which definitely will not work, since that flag was added for a reason.

So actually I expect it to be used like this:

{ stdenv, lib }:
stdenv.mkDerivation {
  name = "foo";
  src = { ... };
  patches = lib.optionals stdenv.targetPlatform.isStatic [./patches/fix-for-static-build.patch];
}

Well, for me... static isn't all-or-nothing and the flag mainly means whether the output for that package will contain *.so or *.a. In practice, I believe libc is the last part that you want to make static (in the sense that you want it static usually only when you make all other libraries static a swell). Still, I do expect most of "static" use cases will be fully static builds, i.e. those you apparently have in mind.

I do not see reason to not build ".o/.a". Put .so into libs, .a into dev (as it is done in Debian).

I don't think that works very well in practice. Many build tools assume they both reside in the same directory, it's more difficult for you to choose which is used, etc. EDIT: most notably, pkgconfig allows different options for static and non-static but libdir is common.

Let's start with

{ stdenv, foo, bar
, static ? stdenv.targetPlatform.isStatic
}:

As @vcunat says as it's a nice small step that nevertheless solves the problem.

Am I correct that you want me to remove manual overrides in pkgs/top-level/static.nix and add static ? stdenv.targetPlatform.isStatic to individual derivations into this PR before we can merge it?

No, sorry, I was just commenting on how we might transition away from having the overlay at all. I didn't realize you had ready pushed new stuff to this. Will review in a moment

@Ericson2314 Did changes as you requested, works for me as checked in #96223 (comment)