Bug#273600: [xml/sgml-pkgs] Bug#273600: After switch to native transcoder, KOI8-R support in xerces23 is broken

[Nikita V. Youshchenko]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> >   With libxercesicu23 problem is not reproducable. It may be a
> >   workaround for now, but requires 'icu' package to be installed
> >   manually.  Anyway, see below.
>
> Why does icu have to be installed manually?  libxercesicu23 has a
> dependency on libicu21c102.  Does it need additional dependencies in
> order for your application to work correctly?  If so, this is a bug
> (in the xerces packaging) that should be fixed.  (I'll experiment with
> this and see if I can figure out what the problem is here, but any
> additional hints you can provide would be helpful.)

libxercesicu23 depends on libicu21c102, but libicu21c102 only recommends=20
icu. So, depending on tool that is used for installation, it may or may=20
not get in.
And without icu, encodings don't work with libxercesicu23.

Btw, just checked *25. Same situation.

> >   > It's possible that the native transcoder supports fewer encodings,
> >   > but we found a handful of other problems that went away when we
> >   > switched from gnu to native.
> >
> >   I've checked the code, by re-building package with debugging symbols
> > and using gdb on the test attached to the original bug report..
> >
> >   Actualy, 'native transcoder' does not support any encodings at all!
>
> Well, it supports UTF-8 and ISO-8859-1, both of which are exercised in
> my test suites.  I guess it isn't able to load any non-built-in
> encodings.

=2D From source file:

  //  This is a minimalist transcoding service, that only supports a local
  //  default transcoder. All named encodings return zero as a failure,
  //  which means that only the intrinsic encodings supported by the parser
  //  itself will work for XML data.

I interpret this as 'for real work, use real transcoders'.

> Rest assured, I am taking this seriously.  Before I switch back to the
> GNU transcoder, I need to study more deeply what was the underlying on
> the bugs that were closed after switching to native.  (I was not able
> to reproduce any of them myself because I don't have access to
> non-i386 architectures.)

AFAIK, people usually give remote access to a debian system with given=20
architecture on request from package maintainer on debian-devel.

> Also, please explain to me why simply using=20
> libxercesicu25 isn't sufficient.

It's probably a sufficient workaround. It just requires more than 6=20
megabytes of otherwise-unneded packages installed (libicu21c102+icu),=20
which is ... somewhat ugly. IMHO, the fact that large disks are aveilable=20
does not mean that those should be filled by crap.

> Alternatively, maybe libxerces{23,24,25}
> should be icu versions (and should provide libxercesicu{23,24,25} for
> backward-compatibility) and the native version should be provided as
> libxercesnative{23,24,25} for people who don't need the additional
> functionality and want to avoid the overhead.

In any case, package description should be exact on what is the=20
'user-visible' difference.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBWcEjv3x5OskTLdsRAkHGAJ946prtvo8Y3tAhKy1fWez4MSnowQCgpZOP
v0/QKY8wUMi3DkXfwHMq1vw=3D
=3DpZJE
=2D----END PGP SIGNATURE-----