On Mon, Oct 19, 2020 at 03:17:54PM +0200, Miguel Ángel Arruga Vivas wrote:
> Hi Efraim,
> 
> I've been taking a look into your patch.  One issue are the comments
> about utf8 and UTF-8, as the issue is already explained in
> make-glibc[-utf8]-locales.

Thanks for taking a look. For the utf8 vs UTF-8 there are a couple of
comments in the code:
The above phase does not install locales with names using
the "normalized codeset."  Thus, create symlinks like:
en_US.utf8 -> en_US.UTF-8

and also:
For backward compatibility with Guix
<= 0.8.3, add "xx_YY.UTF-8".

When I check on one of my Debian boxes:
$localectl list-locales
C.UTF-8
en_US.utf8

I've learned that 'C.UTF-8' isn't from upstream, Debian has a patch for
it. Having written this patch a week or so ago and returning to it I
can't tell you which is the correct one. I think it's best to offer both
so it's not confusing which is correct. That works for the logic for
accepting either in the list of locales, but I'm concerned that skipping
the symlink to the other one could cause problems.

> 
> Other point is:
> 
> Efraim Flashner <efraim@flashner.co.il> writes:
> > +(define* (make-glibc-locales-collection
> > +           glibc
> > +           #:optional (locales
> > +                        '(list "en_US.utf8" "en_US.ISO-8859-1")))
> > (... Removed for clarity ...)
> > +             ,locales)
> 
> I would have used list there like (list ,@locales) or '(,@locales), this
> looks a bit odd to my eyes at least.  I'd expect this kind of calling code:
> 
> (let ((locales '("de_CH.utf8" ... "de_DE.utf8"))
>       (my-glibc ...))
>   (make-glibc-locales-collection myglibc locales))
> 
> Enforcing an extra quotation for no real reason on the calling site, as
> strings are self-evaluating objects, and the use of the symbol list,
> whose meaning depends on other context of execution, doesn't seem
> necessary.  Even worse, my example would raise an error as "de_CH.utf8"
> is not a procedure.

My scheme-foo isn't terribly strong, sometimes I just hack at it until
the code does what I want, and this is one of those times. I've changed
it so that locales takes a list and not an item that is a list.

> What do you think about replacing make-glibc-utf8-locales with a call of
> the new function (using that code) ensuring that the generated
> derivation stays the same for that case (i.e. it's optimized for the
> UTF-8 case)?

This is what I originally wanted to do, but there's a glibc-locales
buried in the bootstrap path so it's not so easy to just swap it out. I
can make the change in core-updates. I'll play around with it and see if
I can come out with the same derivation using a different function, but
I'm not expecting it to turn out identical.

> 
> Happy hacking!
> Miguel
> 



-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted