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

[Steve Langasek]

--vOmOzSkFvhd7u8Ms
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 27, 2005 at 04:00:54PM -0500, Jay Berkenbilt wrote:

> 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.

Thanks, noted.  Still doesn't mean we want to keep this many copies around,
of course. :)

> 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.

I would question whether it makes sense to include an old,
never-before-shipped version of a library in a stable release just for
compatibility with an uspecified library not included in Debian.

> > 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 q=
gis.

> 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.

It looks like we've both filed bugs against gdal now. :)  Thanks for filing
the others.

> > 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.

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.

> > 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.

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.

> You can remove xerces24 from sarge any time.  This will also save us
> from having to deal with the fact that it's still on not-for-us for
> powerpc, mips, and mipsel.

Yes, I'd plucked it out prior to mailing, actually.  And an ftpmaster has
also already removed it now from unstable.

> > 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.  I'll
> ping upstream on its status.

> I've filed bugs against xalan, anon-proxy, gdal, and qgis with
> priority important.  (Since it's only four packages, I didn't go
> through the usual "mass filing" procedure...)  I've also asked Jaldhar
> about xerces24.  Should we wait for responses on these before filing
> the removals?  If you'd like to go ahead and request removal, it's
> fine with me, or if you'd like me to do it, that's okay too.

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.

--=20
Steve Langasek
postmodern programmer

--vOmOzSkFvhd7u8Ms
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCR1RCKN6ufymYLloRAqTnAJ9XS5RPJu6o8svgIjTd2waAa3M4NwCfQbNb
q783FlYbfsv1y/at4mZf2Gc=
=S1U8
-----END PGP SIGNATURE-----

--vOmOzSkFvhd7u8Ms--