GNU bug report logs - #33111
[PATCH 0/3] Have the binary tarball populate ~root/.config/guix/current

Previous Next

Full log

Message #23 received at 33111 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 33111 <at> debbugs.gnu.org
Subject: Re: [bug#33111] [PATCH 0/3] Have the binary tarball populate
 ~root/.config/guix/current
Date: Fri, 26 Oct 2018 11:57:02 +0200

Hello!

Ricardo Wurmus <rekado <at> elephly.net> skribis:

>>> These patches address this by having the binary tarball populate
>>> ~root/.config/guix/current like ‘guix pull’ does.
>>>
>>> There’s one downside though: with the last patch, the ‘glibc-utf8-locales’
>>> is no longer included because ~root/.config/guix/current would be the
>>> wrong place for it.  Consequently, users have to explicitly install it
>>> in ~root/.guix-profile and set GUIX_LOCPATH accordingly.
>>
>> Any comments?  Ricardo?
>
> Thank you for fixing this very confusing situation!  It is very good to
> start out with a

With a what?  :-)

> I’m not sure I understand why ~root/.config/guix/current would be the
> wrong place for the locales package.  It is true that this directory is
> for Guix only, but users don’t need to know about the locales package.
>
> Is it a problem to install the locales package alongside Guix in the
> “guix pull” profile, or is it just inelegant?

It’s inelegant and just a partial solution because ‘guix pull’ won’t
upgrade it.  It would also show up in ‘guix pull -l’, which isn’t great.

> I think it would be unfortunate if older versions of Guix would stop
> working or report warnings when they are used in combination with a
> separately managed profile containing the locales.  The locales need to
> match the glibc version that the program is linked with, so I would
> prefer if we could keep Guix and the locales together.
>
> You know that I find the separation of glibc-locales to be an
> unfortunate tradeoff, which makes using Guix on foreign distros a little
> less convenient.  While I think that this patch set is a definite
> improvement over the current situation, I would be sad to see the
> locales separated and become a source of frustration or confusion.
>
> Is there something we can do about this?  Would it be acceptable to add
> glibc-locales as an explicit input to the result of “guix pull”?  I
> understand that we don’t usually add glibc-*locales as an input, but I
> think in the special case of “guix pull” it could be a reasonable
> compromise / an acceptable exception.  What do you think?

I share your concern but I can’t think of a good solution.

Since ‘glibc-locales’ is big (520M on disk!) and more than what people
need, we certainly don’t want to pull it.  So we’d be pulling
‘glibc-utf8-locales’ as we currently do, knowing that it’s an arbitrary
choice of locales that favors Western countries.

Let’s say we arrange so ‘guix’ is wrapped such that GUIX_LOCPATH points
to a bundled ‘glibc-utf8-locales’.  That solves the problem for the
‘guix’ command, but it doesn’t solve it for other packages installed
with ‘guix’: users would still need to install ‘glibc-utf8-locales’.

A “proper fix” might be to add ‘glibc-utf8-locales’ to
~root/.guix-profile in the binary tarball.  However, as I wrote, it
would require us to improve ‘guix pack’ so it can populate several
profiles, which is not trivial and probably not very useful in other
situations.

On the bright side, ‘guix’ gives users the command to copy/paste to
install locales (commit 26db747a863b08ebcfd630cce635be86c23d829d), so
it’s not that bad.  :-)

Also, we could have the install script run ‘guix package -i
glibc-utf8-locales’ automatically.

Thoughts?

Thanks for your feedback!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.