Change:
set. This can be used to add OpenCL drivers, VA-API/VDPAU drivers etc. ''; }; <ins> setLdLibraryPath = mkOption { type = types.bool; internal = true; default = false; description = '' Whether the <literal>LD_LIBRARY_PATH</literal> environment variable should be set to the locations of driver libraries. Drivers which rely on overriding libraries should set this to true. Drivers which support <literal>libglvnd</literal> and other dispatch libraries instead of overriding libraries should not set this. ''; }; </ins> }; };

Discussion:
Proposal: Make a mesa setup-hook: find opengl programs in $out, fix rpath to point to (or ). Drop .
I'm not certain about all the consequences. It isn't just &ndash; there can also be other required things on that path, e.g. and . But I guess the packages that stop finding libs should be fixable easily by adding the reference explicitly somehow. What might also be a problem: during chrooted builds we have no , so if mesa is removed_ from rpath, I think many executables wouldn't even start due to that dependency, e.g. through libcairo. That would be worked around if we only at the beginning of rpath without removing the mesa reference.
Will this affect people using Nixpkgs outside NixOS?
it should be the same, need for creating manually, or setting another proper . The behavior should be the same as of now, except we don't need which would apply to every binary.
Closely related: there might be a change how libGL implementations are switched. So far only nvidia is known to use that interface, but it's well possible the other major players will jump in soon.
(triage) any action items?
No, just brainstorming here.
(triage) I assume this hasn’t been implemented yet?
There's , which will set RUNPATH in various dispatch libraries to look in , and I suggested dropping the global there, too.
Once I remove from , when I log in via LightDM (as supposed to SDDM or a console login), I still get this in : . Note how there's no 32-bit link and there is also the absolute path to the driver directory (which in my case does nothing because libraries are under ). I'm pretty sure it's coming from . SDDM must be unsetting it while LightDM is letting it through to the user session. We should remove this so it doesn't affect the session, and fix things as necessary by adding RUNPATH to programs that need it (X server, individual display managers, wayland stuff?). I will try with NVidia but cannot try other drivers.
I see two drivers that still rely on to override default system libraries, and .

Not only do they directly provide libraries like , , and instead of using dispatch libraries (, ), they override other system libraries: has symlinks to NixOS builds of a whole bunch of Xorg libraries (e.g. , , ). There is a comment in the package saying it makes some programs work, without explaining why. has replacements of , , and some LLVM libraries (, ). Because NixOS has patched glibc to give priority over , any program that links to one of these libraries will load the one from the AMD drivers. This can result in horrible breakage (what happens to programs that link to LLVM when they get the AMD thing?). This is so ugly and prone to break things that I think we should consider dropping both drivers. If not then we should at least go forward with dropping only for drivers that don't need it (mesa, nvidia).