[xml/sgml-pkgs] Too many xerces versions in sarge: can we get rid of some?

[Jay Berkenbilt]

Executive summary: As we both know, xerces24 is gone now.  I'll try to
make a decision about libxml-xerces-perl quickly.  I'd really rather
see xerces26 in sarge than xerces25, but I could be convinced that
having xerces25 only is better than having xerces26 and xerces25 --
we'll have to see about xalan first.  Obviously if xerces26 is removed
from sarge, it should stay in sid.  Now for the full response...

------

Steve Langasek <vorlon@debian.org> wrote:

> On Sun, Mar 27, 2005 at 04:00:54PM -0500, Jay Berkenbilt wrote:
>
>> I'll answer this since I'm maintaining all of these except xerces21.
>> If the security advisory is CAN-2004-1575, it also impacts 2.4.0.  The
>> most recently uploads address this issue for both versions.  Earlier
>> versions are not vulnerable.
>
> Thanks, noted.  Still doesn't mean we want to keep this many copies around,
> of course. :)

Yes, of course. :-)

>> > Removing xerces23 requires rebuilding/removing libxml-xerces-perl.
>
>> Unfortunately, there is no way to fix this -- the Xerces perl code is
>> tightly dependent upon this specific version of Xerces.  There doesn't
>> seem to be much activity on this upstream and, frankly, even as a fan
>> of the C++ Xerces code (which I use myself -- 2.6 only), I don't think
>> libxml-xerces-perl is a particularly good solution for XML in perl.
>> . . .
>
> Well, if this module is indeed not very useful, and given that
> there's nothing else that depends on libxml-xerces-perl in Debian,
> it might be worth considering removal as an option here.  That would
> be the maintainers' call to make.

I'll check with upstream and on debian-devel and/or debian-user, but
I'll aim to make a decision pretty soon.

> If xalan does need to stay at 25, it's probably best to rebuild gdal
> and qgis against 25 instead of 26 if possible.  They obviously don't
> urgently need the newest version if they're still linked against 21,
> so keeping everything in sync is more important than linking them
> against the most current version.

I'd really like to see 26 in sarge.  2.6.0 has some new functionality
and several bug fixes over 2.5.0 and is the last of the 2.x versions
being released.  Upstream is already working on 3.0.  That said, I
could be convinced that having only xerces25 is better than having
xerces25 and xerces26 even if it's not as good as having only
xerces26.

On a tangentially related note, the xerces packages depend upon
prehistoric versions of ICU.  The top item on my post-sarge to-do list
is to try to take over the ICU packages (I suspect Ivo will agree, and
I've already contacted him about it once some time ago) and bring them
up to date.  Hopefully if the ICU packages are up to date, we can also
get blade to agree to the removal of icu28 so we'll be back to one
version of ICU.  If Ivo agrees to having me take over ICU, I'd package
the latest version (3.2 as of last time I checked) and upload to
experimental, waiting for after sarge to do the transition.  At least
officially, xerces 2.6.0 is required to support ICU >= 3.0, if I
recall correctly.  Of course, this would happen post-sarge anyway, so
it's not a good argument for favoring 2.6.0 over 2.5.0....

Either way, if xerces26 is removed from sarge, it should not be
removed from sid, but I think everyone agrees on that point.

> If we know we want xerces21 and xerces25 to be removed for sarge,
> there's no reason to wait before filing the removal requests.  It
> sounds like it still needs to be decided whether to package xalan
> 1.9 or stick with xerces25 for sarge, though.

We know that the dependent packages build with the newer versions of
xerces, but we don't know whether they work.  If it's okay with you,
I'd like to wait for Berin to test xalan before decide whether to dump
xerces25.  I'm not the maintainer of xerces21, so I don't have a
strong opinion about that.  I wouldn't feel badly about dumping
xerces21 and forcing the maintainers of gdal and qgis to move to a
more recent version to get into sarge.  But it would be more fair to
wait to do this until after we can tell them for sure whether to aim
at 25 or 26 just to avoid the extra upload.

--Jay

-- 
Jay Berkenbilt <qjb@debian.org>