[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32026: [PATCH 05/10] gnu: Add icecat-l10n and icedove-l10n.
From: |
Mark H Weaver |
Subject: |
bug#32026: [PATCH 05/10] gnu: Add icecat-l10n and icedove-l10n. |
Date: |
Sat, 18 Feb 2023 15:22:28 -0500 |
Hi Maxim,
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> Mark H Weaver <mhw@netris.org> writes:
[...]
>> (1) Instead of generating the locales in separate "*-locales" packages
>> and then merging them with the main package (which must then be
>> renamed to "*-minimal"), how feasible would it be to incorporate the
>> locale generation directly into the existing packages?
>
> It's entirely feasible, but I see a couple downsides that explain why I
> stuck with the current design:
>
> 1. The user no longer has an option to install IceCat without the 70 MiB
> or so of extra locales (via icecat-minimal).
>
> 2. The already lengthy IceCat package definition gets even more verbose
> and hard to follow.
>
> 3. The locales are slow to generate (it's sequential, and there are a
> lot of them). Currently they can be generate at the same time as
> icecat-minimal is built.
>
> 4. It makes debugging locale-generation problems more focused.
Okay, that makes sense. Thanks for explaining it.
I didn't realize until now that there's no way, in the current patch
set, to install a subset of language packs. I see that the icecat-l10n
package installs each language pack into a separate output, which led me
to initially guess that users could install a subset of those outputs.
At present, I guess that those separate outputs are not yet usable.
At some point, it would be good to facilitate the creation of custom
'icecat' packages with only a subset of language packs added, but we can
work on that later. There's no need to hold back on this important
first step.
>> (2) In terms of the API, I very much dislike the approach of having the
>> 'make-l10n-package' accept just one argument: a symbol, which it
>> uses to construct the variable names of toplevel variables that must
>> be looked up using 'module-ref'. I'd greatly prefer to simply pass
>> in all of the variables that are needed.
>>
>> What do you think?
>
> I don't feel strongly about it. Since you do, I've adjusted it, in an
> upcoming v3.
Thank you!
Regards,
Mark
- bug#32026: [PATCH 03/10] gnu: Define UPSTREAM-FIREFOX-SOURCE at the top level., (continued)
bug#32026: [PATCH 04/10] gnu: icecat: Make language packs reproducible., Maxim Cournoyer, 2023/02/15
bug#32026: [PATCH 09/10] gnu: icecat: Remove gtk+-2 input., Maxim Cournoyer, 2023/02/15
bug#32026: [PATCH 06/10] gnu: icedove: Automatically load system-provided extensions., Maxim Cournoyer, 2023/02/15
bug#32026: [PATCH 05/10] gnu: Add icecat-l10n and icedove-l10n., Maxim Cournoyer, 2023/02/15
bug#32026: [PATCH 07/10] gnu: Add language packs to icecat and icedove., Maxim Cournoyer, 2023/02/15
bug#32026: [PATCH 08/10] gnu: icedove: Use the locale of the system., Maxim Cournoyer, 2023/02/15
bug#32026: [PATCH 10/10] gnu: icecat: Unbundle nss and nspr., Maxim Cournoyer, 2023/02/15
bug#32026: [PATCH 01/10] gnu: Add a 'update-mozilla-locales' helper for maintenance., Mark H Weaver, 2023/02/16