Re: Problems with handicapped 'bash' from glibc package

[Mark H Weaver]

address@hidden (Ludovic Courtès) writes:

> Mark H Weaver <address@hidden> skribis:
>
>> address@hidden (Ludovic Courtès) writes:
>>
>>> Mark H Weaver <address@hidden> 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:

--8<---------------cut here---------------start------------->8---
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
mhw:~$ 
--8<---------------cut here---------------end--------------->8---

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?

>> I confess that I'm biased, because it would mean throwing away most of
>> the core-updates build outputs my YeeLoong 8101B has produced over the
>> last four days, and starting again from scratch :-(
>
> Yeah, I understand the frustration.  However, I really view core-updates
> as the place where we can make this kind of change without having to pay
> much attention to build time (though I reckon this one occurs close to
> the intended merge date.)

Well, I certainly agree with this general view, and if I felt that this
was a proper fix to the glibc/bash problem, I'd of course agree that we
should do it.

     Mark