Not just making it to Nixpkgs but people not noticing because they have a global library path or not bothering to package something properly.
It also makes solving such issues harder because you’ll have users who are unknowingly able to run some binary while it doesn’t work for others because they don’t have some path present. “Works on my machine” is exceedingly rare in the Nix world outside of hardware issues today and this could conceivably significantly impact that property.
The build sandbox only prevents impurities during the realisation process; at runtime everything is impure and can depend on any path it likes. It can only depend on store paths that it knew ahead of time of course but it could very well depend on global conventional paths such as /usr/lib or behave differently if that path exists.
To be clear: I’m not entirely opposed to the idea of a globally symlinked FHS structure but I do see at least some major flaws and I’m likely missing some because I’m so used to not having it.
Introducing this sort of thing into NixOS would require an RFC IMV though; this is something where we should take great care in considering the impact and potential downsides from as many angles as possible.
The implementation would be trivial and was attempted at least one time already.
I look at it from a different perspective, these users clearly care for some of the things NixOS/nix have to offer.
Insisting that people who cannot figure stuff out by themselves just stay away is elitist; given time and patient explanation I’ve seen plenty of people both understand the issues with the fhs and figure out how to fit things to their use cases.
And I think we really should care not to scare these people away out of simple elitism; FOSS only lives by its community, if NixOS is too hard to use the project will fizzle out; this community is punching far above its weight but I don’t think the bus factor is as big as you’d hope.
So… You’ve not read what I said, since only programs.nix-ld actually produces a global search path.
True. So the concern is that we would lose a degree of runtime safety provided by the absence of global path. And if a package is created that does not attempt to load from global path during build, has no tests, but then loads from global path at runtime, it will build fine but fail at runtime depending on environment setup.
What if NixOS linker treated Nix-built vs non-Nix-built binaries differently? If a binary has RUNPATH referencing Nix store, linker would not look for dependencies anywhere else, probably not even in LD_LIBRARY_PATH which it currently does. But if a binary has no RUNPATH, linker would assume it’s an “alien” binary and would attempt to execute it using user-defined global search path.
It would probably be safer to have the global path be a folder in Nix store too vs a well known path like /usr/lib, so that things like dlopen("/usr/lib/mylibrary.so") wouldn’t accidentally work from Nix binaries.
Please don’t put stuff like this in my mouth. I’ve been answering thousands of questions on 3 different nix*-related platforms for 2 years, and I literally said the learning curve is awful and merits improvement. I do not expect anyone to figure out nix on their own.
I’m saying people should not insist that every project destroy their reason for existence just because it feels a little hard. Learning doesn’t have to be brutal, but sorry to anyone new, it does require some effort, we have to meet in the middle somewhere. If someone is not willing to learn, I’d rather spend time with someone else who is willing to.
You responded to a thread asking for a global search path with a suggestion to use nix-ld. I’m going to guess that the average new user asking for this stuff does not know how to use nix-ld without the NixOS module, and no one who brings up nix-ld provides any caveat that the module is to be avoided or how to even do so.
(I have some other thoughts about wrapping even individual programs with LD* envvars, but that’s for another time, I guess.)
Well, please actually read if you want to discuss something, obviously there will be disagreement if we’re talking about funamentally different things.
My entire point was that you don’t need global search paths with so many alternatives that don’t fundamentally break NixOS.
My problem is with both the module and nix-ld itself. I read your comment in entirety, prior to my responses. In any case, we won’t agree, so no point in going down that path.