Bug#385522: locales-all: add only selected locales
On Thu, Aug 31, 2006 at 11:13:08PM +0200, Javier Serrano Polo wrote:
> Package: locales-all
> Version: 2.3.6.ds1-4
> Severity: wishlist
>
> Current postinst script adds all locales (of course, the name is
> locales-all :)
> This makes current scheme take more disk space than the previous one.
> Using the script provided in bug #375829 is still the best option (using
> supported.tar.gz as the tar file).
>
> The idea was reading the list of locales from /etc/locale.gen.
glibc is frozen and changes have to be blessed by release managers.
It is very likely that they will reject these changes, they are
too intrusive. I decided to be very conservative in order to not
have to fix subtle bugs, hence the current behavior.
We can of course improve it for etch+1.
> There are some possibilities to achieve this:
>
> - Make locales and locales-all depend on a new locales-common (or
> locales-conf, whatever) which contains the debconf files. Or make
> locales, which would contain the debconf files, depend on locales-data
> or locales-compiled.
AFAICT empty packages are normally rejected by ftpmasters.
Maybe a single package containing shared debconf templates for all
packages may do the trick.
> - Copy the debconf stuff to locales-all and possibly add a conflict.
No, it can make sense to have locales and locales-all installed, for
instance if a program reads locale or charmap data files.
You then do not want to reconfigure the locales package, it would be
a waste of time.
> - The size of the new locales-all packages is smaller than I expected.
> It could substitute the locales package ("excess of 30 megs" no more).
But the package size is much larger, so it may be an issue with low
bandwidth.
> - Use a new conf file, /etc/locales-all.gen, that has the list wanted
> locales. It could be initially full (current behaviour), or managed with
> debconf.
>
> If any of these alternatives is acceptable, let me know and I'll help
> with the scripts, though most of the work it's already done.
I prefer the first option, if we can find a way to manage shared debconf
templates.
Denis
Reply to: