[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

xerces upgrade/transition



I'm going to upload xerces27-2.7.0 soon.  This is supposed to be the
last version in the xerces 2.x series.  It has been out for some time,
but I didn't want to upload it until the KDE transition was finished.
(Congratulations on that!)  This should be a near-zero-impact
transition, but I'm alerting the release team as requested.  Details
follow.

I am going to upload xerces 2.7.0 in the xerces27 source package which
will exist (briefly) side by side xerces26 and xerces25.  As
previously discussed, I'm keeping this tradition for now since things
tend to depend upon specific versions of xerces.  At present, there is
a new version of xalan C++ that works with xerces27, so all of the
reverse dependencies of xerces25 and xerces26 except for
libxml-xerces-perl *should* work with xerces27.  My plan is to ask all
the reverse dependency maintainers to switch to xerces27 and, once
that's done, to request removal of libxml-xerces-perl, xerces25, and
xerces26 so that xerces27 is the only 2.x version in etch.  I think
libxml-xerces-perl is pretty much dead upstream, and there are better
perl XML options, so I see no reason to keep xerces25 around just to
support that.  If a version comes out that works with 2.7.0, I'll
continue to package it.  Hopefully this issue will disappear once 3.0
comes out.

Xerces 3.0 is in progress and is supposed to feature a completely
revamped build system making better use of autoconf and libtool than
the current versions.  I haven't followed upstream development enough
to know whether they're versioning symbols.  In any case, my intention
is to upload xerces 3.0 as "xerces" when it comes out and try to do
away once and for all with this multiple versions problem.  Since
xerces 2.7.0 and xerces 3.0 will be incompatible though, it seems
worth handling xerces27 as a separate source package anyway.  If the
3.0 series has the same breakage in this respect as the 2.x series,
I'll revisit this decision when that becomes clear.

-- 
Jay Berkenbilt <qjb@debian.org>



Reply to: