Darwin, again …

Part of the conversation here could be side-stepped by introducing per-platform meta.maintainers. Let’s ignore the implementation details for now and assume that each package has a set of maintainers, that map to various platforms.

We can then use that information to declare if a package is supported for a given platform. If it’s unsupported, it doesn’t become a release blocker. If it annoys you, then become a maintainer of the package!

If we forget about macOS for a minute and think of Risc5 or other interesting architectures, the same problem exists there; not everybody has access to those machines. And the x86_64-linux maintainer might not want to wait on the Risc5 guy to come around. So I believe some mechanism like that is needed anyways.

Another benefit is that it gives users a better picture of which package is supported for which platform. And also encourages their participation if they see a package they like that isn’t supported on their platform.

9 Likes

A problem prefiguring this, though, is that being a package maintainer is neither a responsibility nor a privilege as things stand currently. (I believe there is already an endless discourse thread on this, so hopefully I’ve not re-lit that particular dumpster fire…)

4 Likes

I’d like to re-suggest splitting up Linux and Darwin into separate channels, at least for unstable.

2 Likes

If you can point to specific instances of Darwin blocking Linux advancements in a significant way in recent times, I don’t see why not.

For what it’s worth, the Darwin stdenv rework PR is up. It includes changes to the open-source CoreFoundation to no longer link libcurl. It’s not possible to drop curl from the Darwin stdenv bootstrap completely (because too many things use fetchFromGitHub, unfortunately), but it simplifies the build and should hopefully make changes to curl less painful (because it never makes it to the final stdenv and won’t trip the allowedRequisites check). It should be possible to revert the SystemConfiguration patch once the PR is merged. (I mention this because several curl issues were cited in the Darwin demotion RFC.)

https://github.com/NixOS/nixpkgs/pull/240433

9 Likes

It makes contributing to Nix harder for new comers that don’t own a Darwin machine, for example my first contribution was a Graphical Program that should be supported by Mac and Linux but failed to build on Mac and not having any way of debugging this is really frustrating.

1 Like

All you can be expected to do as a Linux package maintainer is this:

platforms = linux ++ darwin;
broken = stdenv.isDarwin;

Leave it to a Darwin person to do the Darwin stuff. Reach out to the darwin people (i.e. ping @darwin-maintainers), wait a few days and if noone answers your call, broken = stdenv.isDarwin; it is.

9 Likes

Would it be possible to make a virtual darwin remote builder using GitHub - ngi-nix/OSX-KVM ?
EDIT: more stuff: sickcodes/Docker-OSX and kholia/OSX-KVM

1 Like

You could but IMHO, you can’t expect Linux maintainers to do that.

2 Likes

By “do that” you mean write such a remote builder it or use it if it already exists? See the equivalent for darwin maintainers: Nixpkgs 24.05 manual | Nix & NixOS.

Note that even if it existed it would be against the EULA for sure, and the legality of it is a grey area: https://dortania.github.io/OpenCore-Install-Guide/why-oc.html#legality-of-hackintoshing, so I don’t think we should expect people to do that.

But I still want to understand if there was a legal alternative if that could be expected to be used. For example if we had a non-macOS darwin image.

1 Like

Using it, debugging it and, by extent, being in any way knowledgable about Darwin specific stuff such as Frameworks or common issues.

You also can’t expect a Darwin person to fix Linux issues unless they’re also a Linux user.

4 Likes