darwin: generate apple packages preparing for update macos sdk

[holymonson]

Motivation for this change

macos sdk is outdated for a long time (#101229), this PR provides scaffolds and candidates for future updating.
Except for normalizing package name as ${pname}-${version}-${sdkName}, in essence this PR doesn't update any packages. We may want a smooth update process divided into small tasks instead of a large package commit.

Things done

Generate package sources and rewrite some function names.
Will cause mass rebuild due to some derivation names normalized, but it should not cause any actual change in compiling.

cc @matthewbauer

---

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• 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 nixpkgs-review --run "nixpkgs-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.

[holymonson]

Success building all apple packages and the depending bootstrap packages, except #108651.

add cc @siraben @SuperSandro2000

[SuperSandro2000]

I saw this already earlier. If I understand it correctly this should make the update process easier but does not actually change any packages?

Also please change the commit message and PR title to something starting with darwin: or darwin.appke_sdk.

[holymonson]

If I understand it correctly this should make the update process easier but does not actually change any packages?

Yes.

We hesitate to update apple_sdk is mainly because we make up a header-only Libsystem, which is required for bootstrap. But for many other apple packages in apple-source-releases, there are few packages depending on them individual, and could be updated without a mass impact. For example, network_cmds is marked as insecure because of openssl-1.0.2u since 2019, we could keep it up-to-date instead of sticking to osx-10.11.6.

My plan is to take down those light-depended packages one by one, the PR could make it easier.

[nixos-discourse]

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

https://discourse.nixos.org/t/prs-ready-for-review/3032/445

[holymonson]

@veprbl could you review this?

[veprbl]

This is a bit hard to review as orthogonal changes are implemented in one commit, but here is what I saw

[veprbl]

Suggested change

	packages = developerToolsPackages // macosPackages // stubPackages;
	packages = developerToolsPackages // macosPackages // stubPackages;

Do I understand it correctly that developerToolsPackages // macosPackages is a dead code right now?

[holymonson]

Yes, right now it is. Next step if we remove a line in stubPackages, then the package will be updated.

[veprbl]

It would have been more clean to first regenerate the current set with your framework to prove that it works and then do the update separately.

[holymonson]

Hard to do that because you see versions containing multiple versions of sdk and even some of them are fake, I would rather keep it what it is. And I won't update all package in a time, instead, I'm going to create PR later one by one and test to ensure they work. At least in this PR the redundant framework won't take prior than the original stubPackages.

[veprbl]

Well, my thought was that we could still hold on including definitions developerToolsPackages and macosPackages until at least one of the updated frameworks is used. But if you are confident that it will work out the way you've designed, then we could try.

[holymonson]

@veprbl I have rewrite some function name back and add new function with suffix _ , hope this would make it easier to review.

[holymonson]

gentle ping @matthewbauer

[siraben]

LGTM

[bobrik]

Is the order here correct? Should stub packages take precedence over everything else?

I have #105026 locally and it tries to install libutil-47.30.1-osx-10.12.6, which doesn't seem right (and it also fails, because 10.12 doesn't know anything about aarch64).

cc @thefloweringash

[holymonson]

Is the order here correct? Should stub packages take precedence over everything else?

stubPackages does take precedence, the later overwrites the formers.

I have #105026 locally and it tries to install libutil-47.30.1-osx-10.12.6, which doesn't seem right (and it also fails, because 10.12 doesn't know anything about aarch64).

libutil-47.30.1-osx-10.12.6 is in stubPackages, we haven't updated libutil yet, so it still installs the old 10.12 one, that is exactly expected. I'm a bit confused of which version is you actually want.