[charcircuit]

I end up just using patchelf since getting the alternatives working is harder. I would prefer if NixOS is going to give up on moving everything into /nix that it just makes symlinks in the standard paths so users don't need to find something to do it for them.

[rekado]

With Guix we use `guix shell --container --emulate-fhs` to temporarily wire things up to their expected locations:

https://guix.gnu.org/en/blog/2023/the-filesystem-hierarchy-s...

[charcircuit]

    guix shell --container --network --emulate-fhs \
        --development ungoogled-chromium gcc:lib \
        --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose=$XAUTHORITY \
        --preserve='^DBUS_' --expose=/var/run/dbus \
        --expose=/sys/dev --expose=/sys/devices --expose=/dev/dri \
        -- ./VSCodium-1.74.0.22342.glibc2.17-x86_64.AppImage --appimage-extract-and-run

This UX is so bad. I would never be able to remember all of this let alone some noob.

[pxc]

I have thought this, too. But if that includes libraries or even stuff that would go under /usr/share, that could cause breakage on NixOS updates for software that expects specific versions of things at those paths.

This is probably less of an issue for executable paths, but if people really expect to be able to ./configure && make on NixOS, NixOS needs to have a whole different release cycle. Ideally you'd probably still want atypical prefixes, if just like `/usr/1.0/...` or something so you could have multiple releases (and software compiled against them) live side-by-side.

I think that could work really well, but it would be a huge maintenance burden and there's nobody up for it right now. And it would still involve some of the pain we currently have with unusual filesystem structure.