Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nixos/doc/rl-2411: warn about upcoming macOS version requirement #338695

Merged
merged 1 commit into from
Sep 2, 2024

Conversation

emilazy
Copy link
Member

@emilazy emilazy commented Aug 31, 2024

Description of changes

For a long time now, the SDK and minimum target version for x86_64-darwin has been stuck on macOS 10.12. In the past, the minimum SDK was updated quite regularly; at first, the current situation was just because updating the SDKs was excessively burdensome and nobody was up for doing the work, but the introduction of aarch64-darwin with its macOS 11 default SDK has resulted in a long‐term fracture of the two platforms.

Per https://endoflife.date/macos, macOS 10.12 has not received an update since 2017 and went out of security support 5 years ago. Trying to support it in Nixpkgs has been a large burden on the Darwin maintainers, resulting in workarounds, porting work, and even patching functionality out of applications. The existence of Nix users using a macOS version this old is, to my knowledge, entirely theoretical, and we pay in both maintenance costs and functionality: for instance, applications built for x86_64-darwin do not support automatic dark mode switching by default.

This situation has always been suboptimal, but it is now becoming untenable. Python, a critical component of the Nixpkgs standard environment for builds, is dropping support for versions older than 10.13 in 3.13: https://www.python.org/downloads/release/python-3130rc1/. Qt 6 only supports macOS 11 and newer. libuv only supports the versions Apple does, and is a ticking time bomb due to its use in the standard environment. QEMU only supports the last two macOS releases, and won’t build with an SDK older than macOS 12; we previously vendored a set of backporting changes and functionality‐removing reverts to keep it building for 10.12, but this also became overly onerous, and we gave up in #338598.

x86_64-darwin is a platform with a limited upstream future. Apple no longer sells any hardware that runs it natively, and it is unclear how much longer they will support it in the operating system. There are still many users of the platform, myself included, so we shouldn’t drop support for it prematurely, but it’s unreasonable to try and patch the entire world to keep it supporting insecure versions of the OS that only run on hardware that is no longer sold.

Therefore, this adds a release note to warn users ahead of time that 25.05 will only support macOS 11 and newer, as suggested by the 24.05 release team when the possibility of bumping the required version was raised.

Why target Big Sur, rather than any other version? The reason is simple: it’s the same SDK and deployment target as aarch64-darwin. There are many packages that work on aarch64-darwin but not x86_64-darwin, and Darwin maintainers frequently need to be called in to fix things that work fine on the newer platform but not the older one. This change will increase the health of x86_64-darwin by aligning the SDK versions and support between the two platforms; the vast majority of packages that work on one will Just Work on the other. macOS 11 is almost four years old and has itself been out of security support for a year now, but as the first version to support Apple Silicon, it’s a far more compatible base for us to build our Darwin packages for. Any future change in supported versions should be synchronized between the two Darwin architectures.

When 25.05 is released, users on old, unsupported versions of macOS will have the following options:

  • Update to a new macOS version. For users that are on hardware that Apple has dropped support for, OpenCore Legacy Patcher (https://dortania.github.io/OpenCore-Legacy-Patcher/) can enable the use of newer macOS versions on hardware even older than 10.12 supports.

  • Install NixOS. That obviously precludes the use of macOS software (though most of that software has already dropped support for 10.12), but will give users a secure, supported operating system that we can actually own the support for going forward.

  • Keep using 24.11 forever. Since they’re not getting updates to their OS and core applications anyway, this is likely to be acceptable to many users.

  • Switch to MacPorts. They support all the way back to 10.6 for x86_64-darwin by building packages separately for every OS release, though not every package is available for every version.

  • Send patches. We may accept non‐invasive patches to keep certain critical packages (such as the core stdenv packages) building for old OS versions, on a case‐by‐case basis, but we can’t guarantee it. This will ultimately have to be a decision made by package maintainers and personally I doubt this will be a viable path to sustainably support older versions.

cc @NixOS/darwin-maintainers

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

For a long time now, the SDK and minimum target version for
`x86_64-darwin` has been stuck on macOS 10.12. In the past, the minimum
SDK was updated quite regularly; at first, the current situation was
just because updating the SDKs was excessively burdensome and nobody
was up for doing the work, but the introduction of `aarch64-darwin`
with its macOS 11 default SDK has resulted in a long‐term fracture
of the two platforms.

Per <https://endoflife.date/macos>, macOS 10.12 has not received
an update since 2017 and went out of security support 5 years
ago. Trying to support it in Nixpkgs has been a large burden on the
Darwin maintainers, resulting in workarounds, porting work, and even
patching functionality out of applications. The existence of Nix
users using a macOS version this old is, to my knowledge, entirely
theoretical, and we pay in both maintenance costs and functionality:
for instance, applications built for `x86_64-darwin` do not support
automatic dark mode switching by default.

This situation has always been suboptimal, but it is
now becoming untenable. Python, a critical component
of the Nixpkgs standard environment for builds, is
dropping support for versions older than 10.13 in 3.13:
<https://www.python.org/downloads/release/python-3130rc1/>. Qt 6 only
supports macOS 11 and newer. libuv only supports the versions Apple
does, and is a ticking time bomb due to its use in the standard
environment. QEMU only supports the last two macOS releases, and
won’t build with an SDK older than macOS 12; we previously vendored
a set of backporting changes and functionality‐removing reverts
to keep it building for 10.12, but this also became overly onerous,
and we gave up in <NixOS#338598>.

`x86_64-darwin` is a platform with a limited upstream future. Apple no
longer sells any hardware that runs it natively, and it is unclear how
much longer they will support it in the operating system. There are
still many users of the platform, myself included, so we shouldn’t
drop support for it prematurely, but it’s unreasonable to try and
patch the entire world to keep it supporting insecure versions of
the OS that only run on hardware that is no longer sold.

Therefore, this adds a release note to warn users ahead of time that
25.05 will only support macOS 11 and newer, as suggested by the 24.05
release team when the possibility of bumping the required version
was raised.

Why target Big Sur, rather than any other version? The
reason is simple: it’s the same SDK and deployment target as
`aarch64-darwin`. There are many packages that work on `aarch64-darwin`
but not `x86_64-darwin`, and Darwin maintainers frequently need to be
called in to fix things that work fine on the newer platform but not
the older one. This change will increase the health of `x86_64-darwin`
by aligning the SDK versions and support between the two platforms;
the vast majority of packages that work on one will Just Work on the
other. macOS 11 is almost four years old and has itself been out of
security support for a year now, but as the first version to support
Apple Silicon, it’s a far more compatible base for us to build our
Darwin packages for. Any future change in supported versions should
be synchronized between the two Darwin architectures.

When 25.05 is released, users on old, unsupported versions of macOS
will have the following options:

* Update to a new macOS version. For users that are on hardware
  that Apple has dropped support for, OpenCore Legacy Patcher
  (<https://dortania.github.io/OpenCore-Legacy-Patcher/>) can enable
  the use of newer macOS versions on hardware even older than 10.12
  supports.

* Install NixOS. That obviously precludes the use of macOS software
  (though most of that software has already dropped support for 10.12),
  but will give users a secure, supported operating system that we
  can actually own the support for going forward.

* Keep using 24.11 forever. Since they’re not getting updates
  to their OS and core applications anyway, this is likely to be
  acceptable to many users.

* Switch to MacPorts. They support all the way back to 10.6 for
  `x86_64-darwin` by building packages separately for every OS release,
  though not every package is available for every version.

* Send patches. We *may* accept non‐invasive patches to keep
  certain critical packages (such as the core `stdenv` packages)
  building for old OS versions, on a case‐by‐case basis, but we
  can’t guarantee it. This will ultimately have to be a decision
  made by package maintainers and personally I doubt this will be a
  viable path to sustainably support older versions.
@emilazy emilazy added 6.topic: darwin Running or building packages on Darwin 8.has: documentation This PR adds or changes documentation 8.has: changelog significant Novel ideas, large API changes, notable refactorings, issues with RFC potential, etc. labels Aug 31, 2024
@github-actions github-actions bot added the 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS label Aug 31, 2024
@emilazy emilazy removed the 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS label Aug 31, 2024
@ofborg ofborg bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 1-10 labels Sep 1, 2024
@donn
Copy link
Member

donn commented Sep 1, 2024

Relevant good news as well: we might not be stuck with 11 as the max support level for much longer (which is preventing us from compiling, say, lima with vz support): #101229 (comment)

@emilazy
Copy link
Member Author

emilazy commented Sep 1, 2024

Relevant good news as well: we might not be stuck with 11 as the max support level for much longer (which is preventing us from compiling, say, lima with vz support): #101229 (comment)

Yep, Randy’s SDK rework is going to make everything vastly nicer. Though I should point out that we also already have the 12.3 SDK as of #326406, which I used in the QEMU pull request I linked.

@reckenrode
Copy link
Contributor

reckenrode commented Sep 1, 2024

https://discourse.nixos.org/t/on-the-future-of-darwin-sdks-or-how-you-can-stop-worrying-and-put-the-sdk-in-build-inputs/50574 has more details on the Darwin refactor. I have a branch I keep updated with my current work, but I don’t advertise it because the commit history is messy (and it’ll get rebased and force-pushed once I start preparing for a PR).

@emilazy emilazy mentioned this pull request Sep 1, 2024
@nixos-discourse
Copy link

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

https://discourse.nixos.org/t/on-the-future-of-darwin-sdks-or-how-you-can-stop-worrying-and-put-the-sdk-in-build-inputs/50574/6

@wegank wegank merged commit c0df3ae into NixOS:master Sep 2, 2024
32 checks passed
@emilazy emilazy deleted the push-xnqswoxruuln branch September 2, 2024 21:10
@@ -4,6 +4,12 @@

## Highlights {#sec-release-24.11-highlights}

- **This will be the latest version of Nixpkgs to support macOS 10.12 (Sierra).**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **This will be the latest version of Nixpkgs to support macOS 10.12 (Sierra).**
- **This will be the last version of Nixpkgs to support macOS 10.12 (Sierra).**

Typo? I don't think latest can be used to denote the last iteration of something that has ended.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, typo. I’ll try to open a new PR to tighten up the wording here today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.topic: darwin Running or building packages on Darwin 8.has: changelog 8.has: documentation This PR adds or changes documentation 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 1-10 significant Novel ideas, large API changes, notable refactorings, issues with RFC potential, etc.
Projects
Status: Stdenv
Development

Successfully merging this pull request may close these issues.

7 participants