rawhide report: 20060202 changes

Jens Petersen petersen at redhat.com
Fri Feb 3 04:00:49 UTC 2006


On Thu, 02 Feb 2006 22:32:19 +0100
Tomasz Kłoczko <kloczek at zie.pg.gda.pl> wrote:

> On first look m17n it is real piece of crap. Why? Because in
> current form it duplicates many things from libc locale database and few
> more things (did I write "duplicates" ? .. correction: it is not second
> copy of locale/encodings description because second sits in XLOCALE
> [1]).

That is basically why I separated some of the large datafiles to a
separate subpackage (m17n-db-datafiles) so they don't need to be
installed by default.  The main m17n-db package manifest is only 86kB.

> If it is realy neccassary for some importand new package better will be
> invest more energy in (re)development this library for not bloating
> distribution using (IMO) discussabe quality code :>

Well duplication of information (while not desirable) doesn't imply
poor quality per se.

> So .. question is: what is the logic is in include m17n to
> distribution ?

m17n-db and m17n-lib were included in Fedora Core because m17n-db
supports input tables for a lot of languages and it allows much more
sophisticated input maps (eg stateful one) than scim-tables does: for
example Indian Itrans tables can't be supported by scim-tables but they
are by m17n.  So the thinking is to use scim-tables for very large
simple tables like for Chinese and use m17n for smaller complex scripts
and languages, like Indian and European languages.  And SCIM upstream
supports this view too.

Hope it makes a bit more sense now.  m17n-lib supports a gui library
and OpenType fonts (using libotf), but those have been disabled in the
Fedora package.  m17n-db.noarch just includes the minimal datafiles
needed for scim-m17n to work with m17n-lib fwiw.

Jens




More information about the fedora-devel-list mailing list