We are migrating packages that meet below requirements:
1. using `callPackage`
2. called path is a directory
3. overriding set is empty (`{ }`)
4. not containing path expressions other than relative path (to
makenixpkgs-vet happy)
5. not referenced by nix files outside of the directory, other
than`pkgs/top-level/all-packages.nix`
6. not referencing nix files outside of the directory
7. not referencing `default.nix` (since it's changed to `package.nix`)
8. `outPath` doesn't change after migration
The tool is here: https://github.com/Aleksanaa/by-name-migrate.
Rewriting SDK paths is only needed when a text-based stub is an umbrella
framework that does not include the contents of the stubs for the
libraries re-exported by the framework. This is only the case for older
SDKs. Once macOS introduced the dyld cache (and removed system dylibs)
in 11.0, all umbrella frameworks in the SDK include the contents of
their re-exported stubs.
While rewriting newer SDKs is mostly harmless, it breaks Zig, which
tries to interpret the paths relative to the SDKROOT.
sed -i 's/ webkitgtk\b/ webkitgtk_4_0/g' pkgs/**.nix
sed -i 's/(webkitgtk\b/(webkitgtk_4_0/g' pkgs/**.nix
sed -i 's/\.webkitgtk\b/.webkitgtk_4_0/g' pkgs/**.nix
webkitgtk is currently pointing to that specific ABI version but the
alias is going to start warning
This is a new packaging of the Darwin SDK. Instead of splitting
libraries and frameworks into separate packages, it provides a single
package for the whole SDK.
# Features
- Vendored files are removed from the SDK. There are 50+ different
packages that are vendored by upstream (depending on the version);
- Components that are built in nixpkgs (either from upstream or from the
source releases) are also removed. If they need to be included by
default, they are propagated;
- A single SDK pattern is used to package all SDKs, and scripts are
provided to aid updating the SDK version and its source release
versions. This makes adding new SDKs much easier;
- SDK overrides are handled by adding the SDK version you require. If
multiple SDKs are present, only the newest is used. It is possible to
have different SDKs for each of build, host, and target platforms;
- Private headers are no longer provided by default unless you use the
SDK’s `privateFrameworksHook` to add them. It does the right thing
when multiple SDKs are in your inputs;
- Source releases for the SDK version are available via a passthru
`sourceRelease` function. This is mostly useful for getting private
headers for building source releases in the darwin attrset; and
- The same versions of propagated components are used on both platforms
(e.g., the same libresult, libiconv, etc).
See `pkgs/by-name/ap/apple-sdk/README.md` for details on how the SDK
derivation is structured and how to update it.
Reproduction script:
# Bulk rewrite
./maintainers/scripts/sha-to-sri.py pkgs/by-name
# Revert some packages which will need manual intervention
for n in amdvlk azure-cli cargo-profiler corefonts flatito fluxcd gist perf_data_converter protoc-gen-js solana-cli swt verible; do
git checkout -- "pkgs/by-name/${n:0:2}/${n}"
done
