Bug#1003213: locales-all: introduce locales-utf8 package?
Hi,
On 2022-01-06 11:21, Simon McVittie wrote:
> Package: locales-all
> Version: 2.33-1
> Severity: wishlist
>
> As discussed recently on -devel and previously in #701585, at the moment
> Debian users have a choice between two non-ideal locale setups:
>
> * install locales and generate a subset of locale files with locale-gen
> (this is optimal for small systems, but it's difficult for high-level
> UIs like GNOME Settings to present this to users, particularly in a
> non-distro-specific way)
Yes, this is the old way of doing that, and it's something that we want
to get rid of at some point. I think it's important thing to take into
account when discussing the future of locales-all.
> * 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.
> If I'm counting correctly, that would be about 100M, which is perhaps an
> acceptable price to pay for language settings being straightforward -
> a reasonably complete set of Noto fonts (without CJK) is already more
> than half of that.
>
> locales-all could have a Depends on locales-utf8 and contain the remaining
> (legacy national character set) locales, if anyone still needs that.
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, so that wouldn't
solve the problematic of getting rid of the locales package.
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?
> 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.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: