glibc: add "/run/current-system/sw/bin" to the default search path returned by "getconf CS_PATH"

[peti]

This patch changes glibc, so it goes into stdenv-updates.

See http://thread.gmane.org/gmane.linux.distributions.nixos/10967 for a discussion of the issue that this patch addresses.

[vcunat]

@civodul (if that's Ludovic, the nicks sometimes confuse me): why does this work on non-NixOS as well? I would think it also returns "/run/current-system/sw/bin:/bin:/usr/bin" as usually glibc on linux nix is pure, or not?

[civodul]

Vladimír Čunát [email protected] skribis:

@civodul (if that's Ludovic, the nicks sometimes confuse me): why does this work on non-NixOS as well? I would think it also returns "/run/current-system/sw/bin:/bin:/usr/bin" as usually glibc on linux nix is pure, or not?

It works on non-NixOS because it lists /bin and /usr/bin.

Ludo’.

[vcunat]

@civodul: Oh, I overlooked that, right then.

But IMO we should rather create all the /run/* links on non-NixOS and direct them to the right destinations on the particular distribution.

[edolstra]

@vcunat How do you propose to do that? We don't have control over /run on non-NixOS systems.

[vcunat]

@edolstra: IMO that's what non-NixOS packages for nix should do (rpms, debs, etc.).

[edolstra]

But /run/current-system doesn't make sense on non-NixOS systems. What should it point to?

Anyway, /run/current-system is a NixOS-ism that we shouldn't be exporting to other systems.

[vcunat]

IMO it should be a directory... containing links to necessary stuff. It depends. /run/current-system/sw/ could be approximated by /usr/ (although we may be missing stuff from /bin, /sbin and /lib). Some parts don't make sense on non-NixOS, but for others like /run/opengl-driver it's clear what it should contain. I can't say I have a wider knowledge about use cases of /run/ paths in nixpkgs.

[peti]

I use Nix to manage software that's installed on a Linux box on which I don't have super user privileges. On that machine, I cannot create anything in /run -- my store lives in /home/simons/.nix --, so I clearly don't want Nixpkgs software to depend on a /run path in any way, because I cannot control it.

IMHO, it's okay to hack glibc to find executables in /run/current-system/sw/bin for the benefit of NixOS users, but I would not recommend extending this "feature" in any way, i.e. Nix packages should work just fine without that directory.

[vcunat]

@peti: currently we hardcode the /run/current-system path... but it should probably be a parameter like we don't hardcode /nix/store (in cases like yours one can't get binaries from hydra.nixos.org anyway).

These were just thoughts on a more systematic solution of similar problems on non-NixOS nixpkgs (while preserving binary compatibility with the NixOS nixpkgs). I'm certainly not against merging this. And anyway, I personally don't use nix on any non-NixOS machine anymore.

[peti]

@vcunat, you are right that the path returned by getconf should probably be configurable in some way, so that people who don't have /run (or don't want it for some reason) can change these values. In my humble opinion, the best solution for this issue would be for glibc to return getenv("PATH"), and to fall back to these built-in defaults only if $PATH is unset. Anyone who feels strongly about this issue is more than welcome to extend and/or replace the hack I've suggested.

Still, for the time being it seems like hard-coding /run/... is the easiest way to work around the problems some of us NixOS users have had, and it's probably not going to cause any problems for non-NixOS-users either.

Since there was no objection to this patch being merged, I'll close the pull request now.

[vcunat]

Well, currently we hardcode the /run/ paths everywhere, but we could agree on a different solution (e.g. globally configurable).

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/limited-interface-to-system-nix-external-dependencies/25825/1