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

[Ricardo Wurmus <rekado@elephly.net>]

Hi Ludo,

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

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?

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?

--
Ricardo