Bug#273600: [xml/sgml-pkgs] Bug#273600: After switch to native transcoder, KOI8-R support in xerces23 is broken
Nikita V. Youshchenko
"Nikita V. Youshchenko" <yoush@cs.msu.su>, 273600@bugs.debian.org
Tue, 28 Sep 2004 23:52:58 +0400
=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-----