GNU bug report logs - #32026
IceCat locales are missing?

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 32026 <at> debbugs.gnu.org, ludo <at> gnu.org, Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
Subject: bug#32026: [PATCH 05/10] gnu: Add icecat-l10n and icedove-l10n.
Date: Sat, 18 Feb 2023 15:42:38 -0500

Hi Mark,

Mark H Weaver <mhw <at> netris.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>> Mark H Weaver <mhw <at> 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.

It would be nice indeed, and that's what I initially aimed at, until I
realize there was no such ready to use facility in Mozilla products
(there's no easy way to extend the static search path).

I've left the packages public, because the .xpi files can still be
installed manually, perhaps useful for users of other distributions of
of an icecat-minimal user that wants to install a single trusted .xpi.

-- 
Thanks,
Maxim

Previous Next

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