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]>
pgpXg9YM8sWdm.pgp
Description: PGP signature
