guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with handicapped 'bash' from glibc package


From: Ludovic Courtès
Subject: Re: Problems with handicapped 'bash' from glibc package
Date: Sun, 23 Mar 2014 21:27:33 +0100
User-agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux)

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.

> and that would solve this problem and many others.  Therefore, I'd be
> inclined to avoid making this change, and instead work on union.scm.
> I want to optimize it anyway, since it takes over 5 minutes to build
> my profile, which is a bit painful.

Oh, this much?

I have 140 packages in my profile and it takes less than 30s to build
it; that’s an SSD though, so that probably makes a big difference.

> 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.)

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]