Downsides of buildFHSUserEnv

Help
1

What is the downside of using buildFHSUserEnv to build packages? Packaging seems to require less work that way, but it isn’t the norm, so there must be a reason. Why aren’t most packages written with buildFHSUserEnv? What’s the downside of using it?

For background, the buildFHSUserEnv docs say:

buildFHSUserEnv provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root with bound /nix/store , so its footprint in terms of disk space needed is quite small. This allows one to run software which is hard or unfeasible to patch for NixOS – 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries. It uses Linux namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without root user rights requirement.

2

Well for one thing, not all platforms that Nix supports will support buildFHSUserEnv. MacOS doesn’t, and several Linux distros don’t because they disable user namespaces. Secondly, it’s just more complicated. It’s a much simpler design to make the build use the proper native paths out of the gate.

3 Likes
3

It’s a much simpler design to make the build use the proper native paths out of the gate.

If that’s the case, why do we have a shared /etc on NixOS, instead of each program getting its configuration files from its own configuration directory?

4

That is also a very common practice.

1 Like