Creating Root-level Directories and Symbolic Links in Catalina
The use of firmlinks is exclusively reserved for the OS’s own use, but Apple has also made available what are called synthetic firmlinks. These synthetic firmlinks are how the OS enables folks to create directories and symbolic links on the read-only boot volume.
[…]
Whomever designed this came down on the “tabs” side of the “tabs vs. spaces” debate. When creating the separation between installers and Users/Shared/installers in the /etc/synthetic.conf file, you need to use tabs. If you use spaces instead, the synthetic firmlink won’t be created.
[…]
For more information, please see the synthetic.conf man page.
Previously:
5 Comments RSS · Twitter
https://github.com/NixOS/nix/issues/2925
The (awesome) package manager nix still struggles with this. A symbolic link will not help as it is not transparent to installed packages. A mounted volume will help but seems to only work reliably for unencrypted volumes, as encrypted volumes are mounted too late. Someone from Apple was participating early on but after introducing Syntetic.conf seems to have lost interest in the issue.
> The (awesome) package manager nix still struggles with this.
It seems pretty WTF-y to me that their path is not only hardcoded, but apparently so hard for _them_ to change that they'd rather drop macOS support: "Realistically, this may force us to drop support for macOS. Using a different store location for macOS would require a separate binary cache and a separate Hydra instance, and there would be no guarantee that the new location wouldn't break in the future."
Yes, that comment was drastic. I can only assume that it was a knee-jerk reaction on Apple’s “our way or the highway” attitude. Making the root directory read only is also quite WTF-y, if you ask me.
The issue is not that the path is hardcoded but that the paths contribute to the hashed identifiers for a build. You can change the path to nix-root, but then you would not be able to use the binary cache. For many production servers that might not be a problem since you probably want your own package repository and a separate build server, but in day to day use on a developer machine the binary cache is great to have.
> The (awesome) package manager nix still struggles with this.
Seems like someone failed to read the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/pub/fhs-2.3.html). Using /opt/nix would be fine (and expected) on every *NIX.
> The issue is not that the path is hardcoded but that the paths contribute to the hashed identifiers for a build. You can change the path to nix-root, but then you would not be able to use the binary cache.
Ah, gotcha. That part wasn't clear to me from skimming.
Apple is opinionated and arrogant about this sort of thing; you can kind of love it or leave it.
Either way, it seems to me that creating the non-standard /nix directory causes more problems than it solves.
As for FHS, though, surely, the NeXT-derived Applications, Library, Users, etc. directories already sufficiently break that…
