@volth looks like that just got reverted 
.
Would love to see that as a flake or NUR, along with @matthewbauer’s LSB pull request.
When I started with NixOS I saw buildFHSUserEnv as a viable solution, but it (and nix-shell) are not production-ready, at least for software that I use. I’ve encountered a number of segmentation faults that due not occur outside of that environment, particularly when opening large files and processes with high memory / swap utilization. I don’t mean to criticize—I think these are fantastically useful tools—they just aren’t as tested and robust as a vanilla FHS, particularly for scientific/high-performance applications.
One could argue that we should instead “nixify” the world, and indeed many of us have contributed packages needed for our workflows to nixpkgs. But it’s too onerous to require users to make a nix package for everything and we’ll never have 100% coverage.
As such, the only practical solution I see is to capitulate to (de facto) Linux standards, or at least allow users to opt into this without too much effort. Allowing third party binaries to “just work” would be a huge productivity boon, and does not contradict the benefits of Nix.
zimbatm had a nice related post here: [wip] nixos/lsb.nix: init by matthewbauer · Pull Request #78798 · NixOS/nixpkgs · GitHub