I repeatedly run into the case where I’m trying to install a package using nix-env, only to have it not work at all because it has to be installed within my configuration.nix.
The current case in point is zoom-us, which is a video conferencing app (afaict, like Skype). In common with other instances of this issue are that it uses the system’s video card, so it needs to build against the precise versions of the 3d drivers and libraries that are installed on the system.
My glancing blow with this issue makes it clear that it’s not a new discovery, and there are features of Nixpkgs designed to address them, to a degree. (e.g. there’s the unusual situation with how opengl libraries are linked to a non-store path).
What’s the right way to handle packages like zoom-us? Is the fact that they have to be a system-wide install something that can be fixed? Or can we institute a marker of some kind so that nix-env will bail with an informative error?
I sincerely hope I didn’t come off as trivializing the problem. I’ve thought about the issue exactly enough to realize that it’s very deep rabbit hole, and I’m impressed at the amount of effort that’s already been expended on it.
Mostly I wonder if it would be worth adding an annotation to expressions to the effect that “we know this won’t work unless you install them with the kernel, so don’t bother trying to nix-env for the moment”
(As an aside, libGL is one place, but BCC is another - because it compiles eBPF, it relies on details of the running kernel. I suspect there are more cases like BCC that aren’t as well surfaced, because there’s so many more programs that do heavyweight graphics.)
Not at all. Nix shines because all the runtime dependencies can be pulled in the closure. And it breaks down when it’s can’t. It would be awesome to have a generic adapter that can be used to say “I need library XY with such and such ABI”. Unfortunately I don’t have enough C knowledge to know if it’s possible to for example extend the LD-preloader mechanism for that kind of things.