darwin: set the minimum version to macOS 11.3; nixos/doc/rl-2505: announce macOS version support policy #352129
Conversation
emilazy
added
6.topic: darwin
github-actions
bot
added
6.topic: python
6.topic: nixos
emilazy
force-pushed
the
push-nkyqpvqvxwzn
branch
from
18709ea
to
ffa9979
Compare
ofborg
bot
added
10.rebuild-darwin-stdenv
|
|
||
| | Xcode version | SDK version | nixpkgs attribute | | ||
| |--------------------|---------------------------------------------------|-------------------| | ||
| | Varies by platform | 10.12.2 (x86_64-darwin)<br/>11.3 (aarch64-darwin) | `apple-sdk` | |
There was a problem hiding this comment.
Should the entry for the bare apple-sdk be in this table, just to be clear what does it do after the change?
(I know it's described above that it matches the lowest supported, but it may be worth repeating it in the relevant row)
There was a problem hiding this comment.
I’ve added the apple-sdk reference to the same table entry as apple-sdk_11 now that it’s not platform-specific; let me know what you think!
emilazy
force-pushed
the
push-nkyqpvqvxwzn
branch
from
ffa9979
to
f9dd228
Compare
| "11.0" = apple_sdk_11_0; | ||
| }.${stdenv.hostPlatform.darwinSdkVersion} | ||
| or (throw "Unsupported sdk: ${stdenv.hostPlatform.darwinSdkVersion}"); | ||
| apple_sdk = apple_sdk_11_0; |
There was a problem hiding this comment.
does this need to be coupled to darwinSdkVersion with an assert or something? there wasn't one before I added it, which is now getting removed, and seemed like it just broke things like android and iOS eval.
There was a problem hiding this comment.
Hmm, since this is now just a compatibility alias that is going away by the next time this changes in 25.11, it seems fine? I struggle to imagine how it could break Android eval if it’s not even accessing the platform.
I thought about adding an assert to apple-sdk to make sure that the platform fields are updated to the right minor version when the SDK is bumped, but I couldn’t quite think of a properly elegant way to do it, and since our minimum supported macOS release is going to continue to be years old it seems unlikely they’ll get minor SDK updates very often.
There was a problem hiding this comment.
oh yeah, I forget apple-sdk is the thing now -- and since that uses darwinSdkVersion I guess the assert I was looking for is not needed.
| @@ -553,7 +539,7 @@ install_man('man/strings.1') | |||
| strip = executable( | |||
| f'@target_prefix@strip', | |||
| c_args : ['-DTRIE_SUPPORT'], | |||
| dependencies : [libcodedirectory, libprunetrie], | |||
| dependencies : [libcxx, libcodedirectory, libprunetrie], | |||
There was a problem hiding this comment.
weird. I only see strip needed to link with lib stuff
https://github.com/apple-oss-distributions/cctools/blob/7a5450708479bbff61527d5e0c32a3f7b7e4c1d0/cctools.xcodeproj/project.pbxproj#L2221-L2228
There was a problem hiding this comment.
Yeah, so it turns out that the Xcode build system is even more baroque than you can imagine; there’s another file.
| @@ -4,8 +4,6 @@ | |||
| # Project settings | |||
| project('adv_cmds', 'c', 'cpp', version : '@version@') | |||
|
|
|||
| sdk_version = get_option('sdk_version') | |||
There was a problem hiding this comment.
can delete the file meson.options too
emilazy
force-pushed
the
push-nkyqpvqvxwzn
branch
from
f9dd228
to
19dda09
Compare
emilazy
force-pushed
the
push-nkyqpvqvxwzn
branch
from
19dda09
to
4d9fc84
Compare
|
Rebased for conflicts. |
emilazy
force-pushed
the
push-nkyqpvqvxwzn
branch
from
4d9fc84
to
043f42c
Compare
We need to make `-DPRIVATE` unconditional, as it’s required for a XNU header definition that is only used on `x86_64-darwin`, but was coincidentally getting set by a now‐obsolete compatibility shim.
As with ld64, flags added as part of macOS 10.12 compatibility shims (in this case `-undefined dynamic_lookup`) were inadvertently fixing the build. The Xcode project links `otool-classic` and `strip` against `libc++`; why it was previously working on AArch64 without linking against it or passing `-undefined dynamic_lookup`, I can’t fathom.
We need to pull in an additional XNU header for a tool we are now able to build.
emilazy
force-pushed
the
push-nkyqpvqvxwzn
branch
from
f1e9c7f
to
6e157fb
Compare
This changes the minimum macOS version to macOS Big Sur 11.3 for 25.05, as announced in #338695, and further proposes that future Nixpkgs releases are expected to only guarantee support for versions of macOS that are supported by Apple, starting with macOS Sonoma 14 for Nixpkgs 25.11.
Apple only provides security updates for the last three releases. The statistics I’ve found point towards the conclusion that use of unsupported macOS releases drops off very quickly, especially among technical users:
PyPI download stats for Pillow show that 98.35% of downloads were for a supported macOS version (macOS ≥ 11) in July–August 2023.
The author of Downie, a macOS video downloader application, shares statistics showing that 92.35% of users were on a supported macOS version (macOS ≥ 12) in September 2024. In April 2023, the middle of the macOS 13 release cycle, 98.17% of users were on a supported version (macOS ≥ 11); even in December 2022, only two months after the macOS 13 release and around the time a Nixpkgs release would leave support, 97% of users are listed as being on a supported version, although those numbers were from Setapp and so probably cannot be compared one‐to‐one with the later statistics.
When I was discussing version statistics in the Nix on macOS Matrix room at the start of the month, grahamc posted some charts from Determinate Systems data. I believe that one reflected early user data for their downstream Determinate Nix distribution and one reflected ephemeral CI installations using their installer (though I am not sure whether it was for all installations or only Determinate Nix). These charts are naturally going to be skewed by multiple factors and can’t be used as directly indicative of ongoing Nix on macOS usage, but both indicated that essentially 100% of their users are on a supported OS release, with even macOS 12, the oldest supported release at the time, only showing up in the charts as a small slice of GitHub Actions CI runners. (GitHub themselves are removing that runner image on about the same schedule we would drop support for it if we were already following this policy.)
Given this data, the fact that users remaining on unsupported OS versions are unlikely to have too much overlap with those who update to the newest Nixpkgs releases in a timely manner, and the unsafety of using macOS releases that are out of security support, I conclude that it’s not a good use of resources for us to support unsupported macOS versions in new Nixpkgs releases, and we should simply bump our requirements on the same schedule as Apple, as Homebrew does. This doesn’t mean that every package will instantly break for users on old versions; just that we’ll build packages with the newer SDK release and deployment target, and accept that some of the resulting binaries may use new APIs that don’t work on unsupported OS releases.
Keeping our supported versions in sync with Apple will result in fewer build failures because of unsupported APIs, reduced need for manual SDK version overrides to address those failures, and more OS features being utilized out of the box. Some of the FOSS ecosystem is already ahead of us: Qt dropped support for macOS 11 in 6.8, so 25.05 will ship with a minimum supported OS version that hasn’t been able to run the latest Qt release for over half a year. QEMU only officially supports the last two macOS releases, although they mercifully avoided using any features beyond the macOS 12 SDK in the period where we weren’t able to use anything newer. There are always going to be packages that don’t support every macOS version we do, but continuing to lag significantly behind some of the most important software we ship would be counterproductive.
As Apple tends to release new versions (and drop support for the oldest) around September–October, users of the oldest supported macOS release will have two to three months with a supported Nixpkgs version after that macOS release goes out of security support. I think that’s a reasonable buffer given the dynamics of the macOS ecosystem; we’ll still be supporting macOS releases for three years when we only support NixOS releases for seven months. After that, users can install a supported OS (potentially using OpenCore Legacy Patcher for old hardware, or even switching to NixOS), upgrade to the new Nixpkgs release and accept that things may break, continue using the current Nixpkgs release (it won’t get security updates, but neither will their OS), or switch to MacPorts, which keeps support for much older versions.
As far as the 11.3 bump goes, there’s a lot of cruft lying around to deal with the fact that we’ve been stuck on the 10.12 SDK on
x86_64-darwinfor a long time. That can now be cleaned up, reducing the maintenance burden of Darwin support across the project. In this PR, I’ve focused on things required to keep eval working after old SDKs are removed and simple clean‐ups of the SDK and source release packages, the Darwin standard environment, and compiler toolchains. I threw in a Nix change just for kicks, since I introduced that workaround and kind of hate it, and dropped two compatibility hooks that are no longer required. There’s a lot more throughout the tree that can be removed after this – I have almost 100 commits pending in my local branch – but this is a good start.cc @NixOS/darwin-maintainers
Things done
apple-sdk_{11,12,13,14,15}darwin.IOKitToolsdarwin.adv_cmdsdarwin.copyfiledarwin.diskdev_cmdsdarwin.file_cmdsdarwin.libpcapdarwin.libresolvdarwin.mail_cmdsdarwin.network_cmdsdarwin.patch_cmdsdarwin.removefiledarwin.shell_cmdsdarwin.system_cmdsdarwin.text_cmdsdarwin.topgcc{10,11,12,13,14}gtk4haskellPackages.networkhellolibsForQt5.{qtbase,qttools,qttranslations,qtimageformats,qtdeclarative,qtmultimedia}llvmPackages_{13,14,15,16,17,18,19}.{compiler-rt,libcxx}llvmPackages_{15,16,17,18,19}.lldbnixVersions.{nix_2_24,git}python3qt6Packages.qtbasetests.cc-wrapper.defaultnix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.