unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org
Subject: Re: Problems with handicapped 'bash' from glibc package
Date: Sun, 23 Mar 2014 21:27:33 +0100	[thread overview]
Message-ID: <87siq8r77u.fsf@gnu.org> (raw)
In-Reply-To: <8761n4mzvu.fsf@yeeloong.lan> (Mark H. Weaver's message of "Sun, 23 Mar 2014 16:19:33 -0400")

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> 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	other threads:[~2014-03-23 20:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-12  7:12 Problems with handicapped 'bash' from glibc package Mark H Weaver
2014-02-12 13:14 ` Ludovic Courtès
2014-02-12 17:39   ` Mark H Weaver
2014-02-12 19:31     ` Andreas Enge
2014-02-12 20:33       ` Ludovic Courtès
2014-02-12 21:33         ` Mark H Weaver
2014-02-13  9:14           ` Andreas Enge
2014-03-23 16:19 ` Ludovic Courtès
2014-03-23 20:19   ` Mark H Weaver
2014-03-23 20:27     ` Ludovic Courtès [this message]
2014-03-24  3:31       ` Mark H Weaver
2014-03-28 13:48         ` Ludovic Courtès
2014-03-24  3:55       ` Optimizing union.scm Mark H Weaver
2014-03-24 13:45         ` Ludovic Courtès
2014-03-25  7:04           ` Mark H Weaver
2014-03-25 17:18             ` Ludovic Courtès
2014-03-25 22:30               ` Mark H Weaver
2014-03-25 22:58                 ` Ludovic Courtès
2014-03-27  7:09                   ` Mark H Weaver
2014-03-27  9:57                     ` Ludovic Courtès
2014-04-02 14:14             ` Optimizing ‘guix package’ Ludovic Courtès
2014-04-02 16:58               ` Mark H Weaver
2014-03-26 23:29   ` Problems with handicapped 'bash' from glibc package Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87siq8r77u.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).