Bug#1003213: locales-all: introduce locales-utf8 package?
On Sun, 09 Jan 2022 at 13:48:06 +0100, Aurelien Jarno wrote:
> On 2022-01-06 11:21, Simon McVittie wrote:
> > * install locales-all (this costs > 200M but ensures that all locales are
> > available)
> >
> > For "reasonably large" desktop and server systems, I wonder whether it
> > might be better to generate a subset of locales-all with just the UTF-8
> > locales that we recommend for general use, and install that by default?
>
> Defining general use is something quite difficult. All languages and
> countries should be considered equally, so we could differentiate
> UTF-8 from non UTF-8 locales, but we should not make further selection.
Right, what I meant was: AIUI we recommend that all speakers of xx_YY
use the xx_YY.utf8 locale, as opposed to a legacy national encoding, so
we could (make it straightforward to) install all the UTF-8 locales
like en_GB.utf8 and none of the legacy national encodings like
en_GB.ISO-8859-15.
> That way of doing it would be fine from the desktop point of view (100M
> is not that much compared to a desktop environment). However we can't
> force the installation of locales-all-utf8 in d-i
I thought task-*-desktop could maybe pull it in?
> From the various discussion on IRC, we more or less concluded that the
> way to go is to have one locale package per language, like it's done in
> most other distributions. From there we could have task-$language
> depends on locales-$language, also simplifying the d-i side.
>
> Would that work for your use case?
That would mean that UIs like gnome-control-center would still not be able
to offer to add (for example) a French locale on a system that had been
installed in German, unless either the user knows that they need to install
the French language pack first, or the UI grows distro-specific code to:
- know which languages would be candidates for being enabled if the
appropriate language pack was installed
- ask PackageKit to install the necessary language pack when one of those
locales was chosen
However, it's consistent with how e.g. Flatpak handles locales (there's one
locale extension per language code, so for example fr_FR and fr_CH go
together).
This would also allow avoiding a long-standing issue with Steam: some
Steam games assume that en_US.UTF-8 is always available (they're wrong,
and should be using C.UTF-8, but that's not portable), so the steam package
could gain a Recommends: locales-en to work around that.
> > locales-utf8 would probably also be enough for many locale-sensitive
> > packages' test suites.
>
> Not sure about that. Test suites are the main reason why we had to
> revert the removal of non UTF-8 locales.
I suspect this might be a bit circular: the reason that upstreams want
to test support for legacy encodings, and the reason that we want to run
those tests instead of skipping them, is because distros like us still
(claim to) support those encodings, even though we no longer recommend
them.
smcv
Reply to: