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

[Jay Berkenbilt]

Steve Langasek <vorlon@debian.org> wrote:

> Hi folks,
>
> We've noticed that there are a number of versions of xerces floating
> around in testing right now; given that there's just been a security
> advisory for xerces25, I think we should look at getting some of
> these removed from testing prior to release.  What needs to happen
> before we can do that, besides getting packages recompiled against
> xerces26?

Punchline: the right answer is probably for sarge to contain only
xerces23 and xerces26 or for us to completely drop support for
libxml-xerces-perl and release sarge only with xerces26.

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.

The problem with the xerces packages is that each version includes
some incompatible changes, and it's common for external packages to
depend upon specific versions.  I had actually posted to debian-devel
about removing 24, and one developer (jaldhar) specifically wanted it
because of supporting some external library that didn't work with
anything newer than 2.4.  Even so, I have no objection to removing
2.4.0 -- it's a pain to support all these versions.  Perhaps the
situation with his library has changed since then.

> The versions in testing that currently have reverse-dependencies are
> xerces21, xerces23, and xerces25; I've pulled xerces24 and xerces26
> out since they're libraries with no reverse-deps, though of course
> xerces26 can go back in if it's the version we want to use for
> sarge.
>
> Removing xerces21 from sarge requires rebuilding or removing gdal and qgis.

These both build fine with 2.6 as you already noted in your other
message.  I had intended to post bugs against these this weekend
(prompted by the security issue) asking for them to be rebuilt.  I can
do that if you'd like, or you can do it.

> 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.
That said, it was the only XML perl module that could support
validation with DTD and schema support a year or so ago when I last
checked.  However, libxml-xerces-perl doesn't handle Unicode strings
in a sensible way, so I find it to be unusable.  In my own code, I use
an external parser and then just use plain old XML::Parser.

> Removing xerces25 requires rebuilding/removing xalan and anon-proxy.

I talked to Berin about this when xerces26 first came out.  He
believed at the time that xalan would work with xerces26.  I haven't
discussed it with him since.

> How feasible is it to get these packages rebuilt?  If we can at
> least get this down to two versions, that would be a big help; one
> version would be ideal.  3 (or 5, as we had earlier) is excessive.

The right thing to do is to rebuild everything against xerces 2.6.0.

> Can I go ahead and ask for xerces24 to be removed from unstable (or,
> let one of the maintainers do so)?  If we are to target getting this
> down to one version, is xerces26 the one to go for?

No objections to removing xerces24.  We should file bugs against all
reverse dependencies of xerceas21 and xerces25 asking for them to be
rebuilt against xerces26.  Then xerces21 and xerces25 should be
removed as well.  My inclination is to leave xerces23 in place to
support libxml-xerces-perl, but I could be convinced otherwise.

Would you like me to do the rest of the work on this?  I'll track you
down on IRC.

--Jay

-- 
Jay Berkenbilt <qjb@debian.org>