Many thanks for your quick response and to all your good work on getting these releases out. When I saw your message about preparing 3.0.0, I knew it would actually happen. :-)
Boris Kolpackov <[EMAIL PROTECTED]> wrote: >> Going forward, do you think it would be prudent to continue packaging >> xerces so that 3.0.0 and, say, 3.1.0 could coexist, or do you expect >> future migrations from one version to the next to be a little easier >> than with the 2.x packages? > > It might make sense to be able to have both 3.0.0 and 3.1.0 installed > at the same time. Generally, the Xerces-C++ release numbering policy > is as follows: different major releases (e.g., 2.8.0 and 3.0.0) are > interface-incompatible. Different minor releases (e.g., 3.0.0 and 3.1.0) > are interface-compatible but binary-incompatible (that is, applications > will need a recompile but no source code changes are necessary). Finally, > different build releases (e.g., 3.0.0 and 3.0.1) are binary-compatible. > Therefore, I think the current packaging schema is the most appropriate > one. The release numbering scheme you've described sounds quite sensible and standard. However, based on your answer, my inclination would be to change the debian packaging scheme to support only one version of xerces 3.x in the archive at a time. This is a different conclusion from the one I think you've indicated, so I'll explain my reasoning. Read on if you're interested, but don't feel like you need to spend more time on this. It is the general practice within debian not to have multiple source-compatible versions of a library in the archive at a time. When a source-compatible but binary-incompatible release of a package is made, the source and development package names stay the same, but the package containing the runtime libraries gets renamed, and we force a "library transition" in which all depending packages must be recompiled. As long as we keep the development package name the same, this is little or no work for package maintainers as the release team can automatically trigger such recompilations. Packages in transition become temporarily uninstallable in the unstable distribution, but they remain working on existing systems since the old and new runtime library packages can coexist. Ordinarily, I would just handle xerces-c this way without even asking, as I have done with all my other packages. The only reason I bring up the question at all is that, in the past, it has not always been the case that subsequent minor releases are source compatible. At least, this is the case with XML::Xerces (a.k.a. xerces-p, or debian package libxml-xerces-perl) which depends on a specific minor version of xerces-c. If I go to my strongly preferred policy of supporting only one source-compatible version at a time, then packages that work with one version but not with a subsequent minor release of the same version will get left behind. If the only such package is libxml-xerces-perl, then I don't think I'll keep multiple source-compatible versions around just for it. If it's reasonable to expect other packages to have the same issue, I may then want to stick with the current policy. I'll also ask on [EMAIL PROTECTED] The reason I'm not so worried about libxml-xerces-perl is that, according to popcon (debian's "popularity contest", which counts users of packages on systems that voluntarily participate), only 0.03% of debian systems actively use libxml-xerces-perl. This is 18 systems among those who use popcon. Although I hate to see a package dropped from the archive, I'm not sure libxml-xerces-perl is enough of a reason to incur the overhead of maintaining multiple simultaneous source-compatible versions of xerces-c in debian. There is also a bug reported against it that it fails to build with perl 5.10, though there seems to be a fix for this floating around -- I haven't really investigated yet. >> For those of you who are debian users, but what I'm really getting at >> is whether the source package should just be xerces-c or whether it >> should be xerces30 or something like that (analogous to the current >> xerces27 and xerces28 packages). Likewise, the development packages >> could be libxerces-c-dev instead of libxerces27-dev, libxerces28-dev, >> etc. > > Hm, I agree there should be libxerces28 and libxerces30. However, I > think there should only be one libxerces-dev since one cannot have > both, say, 2.8.0 and 3.0.0 headers installed at the same time (they > all end up in /usr/include/xercesc). In other words, a user can have > several versions of libxerces-c.so installed but the development > happens against only one version. There has to be a separate -dev package for each source package, though it's okay if libxerces-c-dev belongs to the most recent one and older ones, if any, have a numbered libxerces-cnn-dev package. This is how the Berkeley DB packages are managed. The debian packaging system allows conflicts to be named, and that's the mechanism by which people are prevented from having both versions installed at the same time. --Jay --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
