[Nix-dev] Re: NixOS has a non-conforming value for _CS_PATH. Do we care?

[shea at shealevy.com]

> Hi Shea,
>
> Shea Levy <shea at shealevy.com> skribis:
>
>> glibc hard-codes confstr(_CS_PATH, ...) to be /bin:/usr/bin, which
>> obviously on NixOS cannot "be used as a value of the /PATH/
>> environment variable that accesses all of the standard utilities of
>> IEEE Std 1003.1-2001", rendering NixOS non-conforming with POSIX as
>> far as I can tell. Does anyone care about this? Does anyone have any
>> way to fix this without hard-coding paths to, e.g., coreutils in
>> glibc?
>
> I think we should patch libc’s sysdeps/unix/confstr.h to use
> "/var/run/current-system/sw/bin" as its value.  This path allows access
> to “all of the standard utilities”, as POSIX puts it.
>
> WDYT?
>
> Ludo’.
>

For now, I think it's the best solution. I'd prefer a static solution and
one that will work on non-Nixos systems, but neither goal seems readily
achievable given current tools.

Once multiple outputs are working, however, I think we can have a better
solution. The general idea (using only coreutils as an example) is to
first build glibc with _CS_PATH hard-coded to the coreutils used to build
glibc, then have a two-output build that first consists of copying over
the first glibc, rewriting that glibc's self-referential hashes to point
to the new output, building coreutils with the new glibc, then rewriting
the new glibc's hashes pointing to the old coreutils to point to the new
coreutils. There are several complexities with this (for example, the
bootstrap coreutils will have to have the same name as the final coreutils
so only the hash has to be overwritten), but I don't think they're
insurmountable and the end result would be something like:
/nix/store/hash-posix-coreutils and /nix/store/otherhash-posix-glibc,
where each has hard-coded references to the other. I've been thinking
about this for a while and obviously don't have any working example code
to illustrate the idea, so please let me know if the explanation was
confusing. If it wasn't confusing, what do you think as a long-term
solution? With the right amount of bootstrapping, we can use this
technique not only to have a correct _CS_PATH but also to get rid of all
the hard-codes to /bin/sh and instead hard-code to a store output. In
general, the technique can be used to solve most (all?) cyclic runtime
dependencies without dynamic lookups like $PATH.

Cheers,
Shea