For quite a while, there have been multiple versions of xerces in the
debian archive.  With 3.0.0 now finally in beta and the release being
managed by someone who will likely get it done in a timely fashion,
I'm hoping to take advantage of this opportunity to clean things up.

3.0.0 is not source-compatible with the 2.x series, and according to
upstream, there may be packages that require significant effort to
port from 2.x to 3.x.  I would therefore like to support only one 2.x
version and only one 3.x version in the archive at a time.  Once all
packages in debian that use the 2.x series have been ported to 3.x, we
could consider dropping the 2.x packages, unless there is some demand
to support things that aren't debian packages.

There is one likely casualty with this strategy: libxml-xerces-perl.
That specific package, and as far as I know, only that package, seems
to be tied to a specific minor version of xerces-c and is not really
being actively maintained upstream, though they do occasionally
release.  Given that popcon indicates only 0.03% of popcon users use
libxml-xerces-perl regularly (it gets just 18 "votes"), it doesn't
seem like enough of a reason to keep multiple source-compatible
versions of xerces-c in the archive at once.

Can anyone see any serious problems with the decision to support only
one source-compatible version at a time (consistent with just about
everything else in the archive) even knowing that this might cause
libxml-xerces-perl to have to disappear from the archive?  I hope to
have xerces27 removed before lenny releases anyway, and the only
reason I haven't pushed people to transition from xerces27 to xerces28
is because I was hoping to do this reorganization in time for lenny.

I haven't tested this yet, and I would thoroughly test it before doing
anything, but here's what I'm thinking: right now, we have source
package xerces28 that creates libxerces28, libxerces28-dev, and
libxerces28-doc, and we have source package xerces27 with the
analogous binary packages.  My inclination is to upload 3.0.0 as
source package xerces-c, a source package that would always contain
the latest upstream release of xerces-c.  It would install
libxerces-c3.0 (the runtime library is libxerces-c-3.0.so, similar to
how the Berkeley DB packages are set up, rather than the more accepted
such as libxerces-c.so.30.0.0), libxerces-c-dev, and libxerces-c-doc.
The libxerces-c-dev package would provide libxerces-c3-dev and
conflict with libxerces-c2-dev, libxerces28-dev, libxerces27-dev, etc.
The libxerces-c-doc package would provide libxerces-c3-doc.  Then I
would reupload xerces28 as source package xerces-c2.  It would create
binary packages libxerces-c28 (which installs libxerces-c.so.28.0),
libxerces-c2-dev, and libxerces-c2-doc.  The libxerces-c28 package
would provide libxerces28, the libxerces-c2-dev package would provide
libxerces28-dev, and the libxerces-c2-doc package would provide
libxerces28-doc to make transitions from the xerces28 packages
seamless and automatic.  I would then request removal of the xerces27
and xerces28 packages.  If we don't have a version of
libxml-xerces-perl that works with the latest 2.x or 3.x versions of
xerces-c, I would also request removal of libxml-xerces-perl.  I'll
have to test this scheme carefully to make sure it works, but I think
it will work fine.

Comments?

-- 
Jay Berkenbilt <[EMAIL PROTECTED]>

Attachment: pgpXg9YM8sWdm.pgp
Description: PGP signature

Reply via email to