Maybe. In my eyes this very much depends on what hides under the vague description of
automatically wrap packages with a code that picks the appropriate glibc
And I meant I’d rather explore other ways, adapt the OpenGL libs and not all other SW. For example, make our OpenGL binaries less demanding around glibc version. (by this I didn’t mean I’d invest much of my time into it, though)
Another way to explore IMHO is to load the free drivers (mesa) in a pure way. I suspect that would even be easy, at the cost of:
The biggest problem with that approach is that you wouldn’t be able to run old apps on any hardware more recent than what Mesa supported at the time. If some new AMDGPU came out later this year, you wouldn’t be able to use it with a package from today.
Ideally hardware drivers could become another distinct hardware abstraction layer with extremely stable APIs like the kernel is. (As long as they’re using generic UNIX-ish syscalls, you could probably run ancient binaries on most modern kernels and vice versa; see i.e. containers.)
I suppose libcapsule would be the way to achieve that. Drivers would have their own libc and friends for their internal operations and apps would still use their own libs too but I don’t know how feasible this would be.
This just sprung to my mind though: Wouldn’t it be even better to have some sort of more separate interface here? Like a socket or something? A vulkand would listen on it using a standard API and apps send messages over it to do Vulkan things.
No idea how feasible this would be as you’d have to somehow do presentation in the application still and you can’t just copy frame buffers back and forth all the time.
note that i’ve prompted a Nix hour on this topic a while ago
my takeaway is that the way forward is a wrapper abstraction layer
which can then fall back on the system libGL on non-NixOS (or older NixOS i suppose)
It normally doesn’t (unless you tell it to). It just deploys stuff at addDriverRunpath.driverLink and programs from nixpkgs already know to look up the missing drivers there
Unless I’m mistaken, in case of libGL specifically this isn’t only an NVidia limitation: libgbm should be impure · Issue #269419 · NixOS/nixpkgs · GitHub.
Note that use-cases like “using the host system’s (e.g. ubuntu’s) python with native extensions from nixpkgs” would remain broken because the host system’s python would load the old libc before it loads your wrapper.
Rearranging Nixpkgs so that we build against an older glibc but link a newer one for deployment like @vcunat suggests is more promising