I began working on belocs-locales-data in October 2004, to include most
patches sent to Debian BTS and upstream bugzilla. From the beginning,
it was pretty obvious to me that I needed also to fork localedef,
because having iso-*.def hardcoded in localedef makes transitions much
harder, e.g. users cannot change their currencies on an old system when
a country makes such a change. For a similar reason, I also dislike the
strong correlation between locales and libc6 packages.
When working on improving locales, it became more and more obvious that
localedef is really buggy. The first encountered problem was with
Dzongkha locale, it needs many collation elements and GNU localedef
loops forever when it encounters more than 256 collating elements.
After sending patches to BZ368, I implemented these changes as a concept
of proof, and so far I was told that Dzongkha locale works fine with
belocs-locales-data.
After more digging into GNU localedef internals about collation, I filed
BZ645 with test cases. I did not receive any answer to bugreports sent
against localedef, and from there did not sent all my patches to
upstream.
In this mail, I will describe the patches applied against
belocs-locales-bin (which ships locale, localedef and locale-gen
programs), so that we can discuss which ones could be merged into libc6
or pushed upstream. I will prepare dpatches to apply to glibc-package
on the issues which you believe are worth getting from
belocs-locales-bin.
In a later mail, I will explain the changes applied against
belocs-locales-data, but some changes (like the Dzongkha locale) need
patches to be applied against localedef, so I prefer to discuss these
ones first.
Instead of discussing several issues in the same thread, it would
certainly be a good idea to have an issue per reply. Feel free to start
a new thread if you prefer.
Patches in belocs-locales-bin are maintained with quilt, which means
that there is a debian/patches/series file listing patches in the
desired order. The debian/patches directory is temporarily online at
http://people.debian.org/~barbier/tmp/belocs-locales-bin/patches/
A. Changes in locale-gen
=-=-=-=-=-=-=-=-=-=-=-=-
As locale-gen is not an upstream program, there is no patch here.
The current script is temporarily available at
http://people.debian.org/~barbier/tmp/belocs-locales-bin/locale-gen
The main differences with locale-gen from the locales package are:
* It accepts few command-line options, and can also be driven
by a configuration file /etc/belocs/locale-gen.conf:
--purgeremove existing locales before processing
--archive store compiled locale data inside a single archive
--no-archive do not store compiled locale data inside a single archive
(default)
--aliases=FILE read locale aliases from FILE. (Default: /etc/locale.alias)
* It detects the magic number currently used by GNU libc for compiled
locale data, and tells localedef to write compiled locale data
suitable for this format, if it is supported. E.g. my localedef
supports both 2828 (glibc = 2.1.96) and 20031115 (glibc = 2.3.3)
magic numbers for a long time; when I upgraded to glibc 2.3.5-3, I was
not forced to upgrade belocs-locales-data, I only needed to re-run
locale-gen so that locales are compiled into the right format.
Of course it would be much better if this rebuild was triggered by
libc6, but this is another story ;)
* It keeps tracks of dependencies between generated locales and locale
source files, so that locales are generated only if some source
files needed for this locale have been modified, or if the magic
number changed. The --purge command-line flag tells locale-gen to
purge everything before processing locales.
This is very convenient on slow machines (yes, mine is very slow).
* By default, locales are written into the old format (not into an
archive file). My motivation was that if someone needs to add a
local locale, she can compile her locale into $HOME/share/locale
and set LOCPATH to $HOME/share/locale:/usr/lib/locale if she
wants to use either her preferred locale or a system one, e.g.
with LANGUAGE=xx_XX:de
But this will work only if system locales are compiled in old
style, not with archive. I also made benchmarks to see if
archive was faster, and IIRC noticed no significant difference.
This behavior can be overridden by the --archive flag.
B. General changes to compile locale and locale-gen
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
* autotoolize.diff standalone_build.diff
These 2 patches are to compile belocs-locales-bin outside of glibc,
and have no interest for you.
C. Changes in locale
=-=-=-=-=-=-=-=-=-=-
* locale_print_LANGUAGE,diff
This patch prints the LANGUAGE variable on output, if it is set,
when locale is called without argument.
D. Changes in localedef
