[bug#44075] [PATCH] gnu: Add make-glibc-locales-collection.

[Miguel Ángel Arruga Vivas]

Hello,

Efraim Flashner <efraim@flashner.co.il> writes:
> Thanks for taking a look.

No problem at all, I was thinking about something along these lines too,
but then I saw your patch. :-)

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

Yes, what I mean is that the comments along the code may need to be
clarified, but adding a "nobody knows" doesn't add much information.
The actual source[1] says that the correct value is utf8, following
the rules for the 'normalized codeset' naming, that I copy here:

  1. Remove all characters besides numbers and letters.
  2. Fold letters to lowercase.
  3. If the same only contains digits prepend the string ‘"iso"’.

We should stick to that naming regarding libc locales (note to self),
even though we keep the links for compatibility.  That includes the
other locale at en_us-glibc-locales.

>> 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 guess you mean glibc-utf8-locales, if not I'm missing where that
reference could come from.  That's why I insist on leaving exactly the
same derivation.

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

The colour of my lisp-rate belt isn't even close to some you can see
around here but I could bring you some help if you want, because I think
it's easier to do it without any change in current packages than it
might sound.  Not the definitions in scheme, of course, I mean the
derivations the daemon actually sees.

Said this, I've seen that [single-]locale-directory does mostly the
same, and there is a build-locale function in gnu/build/locale.scm... so
I'm starting to see as a better idea to clean up glibc-utf8-locales up
in core-updates using the latter, as it would lead to cleaner code for
the builder.

Could you check that and tell if you consider feasible what I propose?

Happy hacking!
Miguel

[1] info "(libc)Using gettextized software"