Mark H Weaver <[email protected]> skribis: > [email protected] (Ludovic Courtès) writes: > >> Mark H Weaver <[email protected]> skribis: >> >>> [email protected] (Ludovic Courtès) writes: >>> >>>> Mark H Weaver <[email protected]> skribis: >>>> >>>>> The 'bash' in the glibc package is handicapped in at least two ways: >>>>> >>>>> * It can't set the locale, because it looks for locales in >>>>> >>>>> /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-intermediate-2.18-locales >>>>> >>>>> * It can't look up anything from NSS, such as passwd data, because it >>>>> tries to load the modules from >>>>> /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-intermediate-2.18 >>>>> >>>>> There are two problems that need to be addressed, I think: >>>>> >>>>> * Users could easily end up with this handicapped 'bash' as their >>>>> primary bash, if they installed (or upgraded?) 'glibc' since the last >>>>> time I installed 'bash'. This happened to me, for example. >>>> >>>> I realized that this particular problem is easily solved by moving >>>> glibc’s bash away from $bindir, for instance to $libexecdir. >>>> >>>> I’m trying it out locally, and plan to commit to core-updates if >>>> everything works as expected (hopefully as the last core-updates >>>> change.) >>>> >>>> Thoughts? >>> >>> Hmm. We need a more intelligent union.scm anyway, >> >> Agreed, but that’s a separate issue. >> >> Having it in $bindir also means that patch-shebangs can pick it up, >> which is usually not what we want. >> >> So I think it really makes sense to move it out of sight. > > Well, that's sweeping it under the rug, when actually this broken bash > should never be used for anything except perhaps during the bootstrap. > > The fact is, we have broken 'system' and 'popen' functions in Guix. > For example: > > mhw:~$ cat foo.c > #include <stdlib.h> > > int > main (int argc, char *argv[]) > { > return system ("echo Hello world"); > } > > mhw:~$ gcc -o foo foo.c > mhw:~$ ./foo > sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) > Hello world
Yes, understood. > Our glibc should not use a broken bash. It would also be nice if the > bash used by glibc was linked with the same glibc, so that we only need > one copy of glibc in memory. So there's a circular dependency here. > > I think we need a better way of dealing with circular dependencies in > general, but in the meantime, I think we should build the final glibc > and bash as two outputs from the same derivation, so that they can refer > to each other. > > What do you think? Again, I definitely agree. We discussed ways to do it here: https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00145.html Someone just needs to do it. :-) We could schedule it for the next core-updates round, WDYT? Note that technically, it cannot be two separate outputs because outputs currently cannot have circular references (and it wouldn’t buy us much anyway.) Ludo’.
