[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#374997: in NEW: utf8-migration-tool -- Debian UTF-8 migration wizard



su, 2006-12-31 kello 18:55 +0500, Alexander E. Patrakov kirjoitti:
> Martin-Éric Racine wrote:
> > Having merged Vincent's patch, I uploaded utf8-migration-tool to NEW.
> > 
> > Since Etch will be Debian's first UTF-8 release - implying a migration
> > from legacy encodings for those upgrading from Sarge, which is precisely
> > what this tool tackles - it would be nice to approve it for Etch.
> 
> Hello,
> 
> 1) patrakov@home:~$ utf8migrationtool
> Unexpected error: exceptions.IOError
> Traceback (most recent call last):
>    File "/usr/bin/utf8migrationtool", line 40, in ?
>      dmrc = getconfig()
>    File "/usr/bin/utf8migrationtool", line 34, in getconfig
>      config.readfp(open(os.path.expanduser('~/.dmrc')))
> IOError: [Errno 2] No such file or directory: '/home/patrakov/.dmrc'

Works fine here, so no comment.

> 2) The tool must handle the already-migrated case better (e.g., by adding a 
> line about that onto the second screen).

It does. Here, it says that the locale is already migrated. It also says
that it cannot find any files utilizing a legacy encoding.

> 3) The legacy locale for Russia is ru_RU.KOI8-R, not ru_RU, and the 
> migration tool must handle this special case.

Russian is a messy case. Too many encodings, more than half of which are
OS-specific or otherwise standards that never gained momentum.  This is
further complicated by usage cases: while Unices tend to go for KOI8-R,
users that need to interact with Windows use CP1251 instead. Still, it's
up to Russian developers to add support for this; upstream simply cannot
anticipate every possible exception.

> 4) migration of encodings is only a part of the game. The most important 
> part is to deal with packages that do not work correctly in UTF-8 locales 
> and cannot be fixed (e.g., a2ps). Since this part cannot be automated (as 
> nobody has created such blacklist), I suggest mentioning this obstacle in 
> the manual page and on the welcome screen.

Remaining UCS issues really belong in Etch's release notes, since it is
Debian's first release claiming UTF-8 support.

> Thus, I cannot recommend migration of this package to Etch in its current shape.

I'd still go for it. Applications for which upstream cannot be bothered
with supporting UCS or locales that create exception cases are not an
excuse to deprive users of this tool.

-- 
Martin-Éric Racine
http://q-funk.iki.fi




Reply to: