erofs-utils: enable running on darwin

[nikstur]

Description of changes

Enable erofs-utils to build on Darwin. This is especially interesting because it enables darwin.builder to use virtualisation.useNixStoreImage = true; and virtualisation.writableStore = false; at the same time. With this combination of options an erofs image is built just in time inside the script that calls QEMU.

Doesn't currently build because of #236560

#239248 introduces a fix.

As a stopgap solution, tests for perlPackages.Po4a are disabled in b226d46840f6b20ec0d2072c41678a5a5b184368
When a proper solution is added to Nixpkgs, the corresponding commit can be removed.

For reference, the homebrew formula for erofs-utils: https://github.com/Homebrew/homebrew-core/blob/e4660044d3e2d53f5a74efd079bf29af2bd3f12a/Formula/erofs-utils.rb

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• 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/)
• 23.11 Release Notes (or backporting 23.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.

[emilazy]

Very cool. Successfully tested {mkfs,fsck}.erofs on x86_64-darwin; not familiar enough with erofs to do anything more expensive.

Does this mean we could avoid the Darwin builder having any persistent state at all? I didn't realize the remote builder protocol could work with an immutable store. Would there be a startup time impact from making the image or is it scoped down to only the required components for the builder that shouldn't change often?

[nikstur]

Would there be a startup time impact from making the image

Yes there would be an impact. See the original commit for more info: afc60d0

If we can build erofs images on MacOS too, however, we could get rid of the storeImage in the qemu-vm which uses lib/make-disk-img.nix, producing a derivation (which is then cached). To add persistence to the Store image we could just mount an overlayfs over it (like we already do in many other places). By doing that we could get rid of this warning: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/qemu-vm.nix#L934

Even if every test that uses a Nix Store image is a little bit slower, I think overall it would be still a big win to not cache so many mostly useless images anymore.

[prusnak]

Nit: platforms = platforms.unix is more appropriate

[ghost]

Erofs is a Linux thing.

[RaitoBezarius]

@ehmry Closing PRs like this is quite rude, EROFS is a Linux filesystem sure, but there's nothing that says you have to use Linux to write stuff related to that filesystem, is there?

[Janik-Haag]

I'm reopening this since it seems like this was closed prematurely and people doing the work to make stuff build on officially unsupported platforms usually is a good thing.

[ghost]

I wan't aware that FUSE was permitted by Apple, so I was in error to close this issue. I still don't think accommodating Apple users is helpful.

[Janik-Haag]

I still don't think accommodating Apple users is helpful.

that is another discussion entirely. I think piegames posted about this on discourse a few days ago.

[RaitoBezarius]

I wan't aware that FUSE was permitted by Apple, so I was in error to close this issue. I still don't think accommodating Apple users is helpful.

Is your point, you don't want to maintain a Darwin-enabled erofs-utils? In that case, would someone else taking ownership of that part as a co-maintainer enough for you?

[emilazy]

I don't think this is about FUSE. mkfs.erofs works fine on Darwin. Why close a working PR with a clearly-stated rationale?

[Janik-Haag]

@ehmry made a mistake, they acknowledge it. Everything should be fine now. Can we get back on topic of the pr? If you want further discussion I suggest you to move it to matrix or discourse but a pr is not the place for this,

[nikstur]

Thank you @wegank for removing the "offending" commit that caused massive rebuilds :D.

@ehmry I'm happy to co-maintain the package to take some of the (Darwin) burden off of you.