On Tue, May 17, 2005 at 05:18:41AM -0500, Dirk Eddelbuettel wrote: > | $ dpkg -c q/quantlib/libquantlib0_0.3.9-1_i386.deb |grep libQuantLib > | -rw-r--r-- root/root 5192416 2005-05-02 22:22:23 > ./usr/lib/libQuantLib-0.3.9.so > | -rw-r--r-- root/root 208464 2005-05-02 22:22:23 > ./usr/lib/libQuantLibFunctions-0.3.9.so > | lrwxrwxrwx root/root 0 2005-05-02 22:21:47 ./usr/lib/libQuantLib.so > -> libQuantLib-0.3.9.so > | lrwxrwxrwx root/root 0 2005-05-02 22:21:57 > ./usr/lib/libQuantLibFunctions.so -> libQuantLibFunctions-0.3.9.so
> | The soname of the quantlib library has been changed, but the package name > | has not. Since there are packages in woody which have a Depends: > That's been the case since upstream started encoding the soname in the > package name some time in the 0.3.* release series, yes. While this is better than *not* changing the soname, it is not a very good practice. The soname should be changed when the library's ABI changes incompatibly; no more, no less. If you are concerned about this impacting your Debian maintenance, I would encourage you to set quantlib upstream straight about the significance of Unix library SONAMEs. > | libquantlib0, this is a release-critical bug because it invalidates the > | shlibs from libquantlib0 in woody and breaks partial upgrades between stable > | releases. E.g., consider a user who has quantlib and quantlib-python > | installed on woody, begins transitioning to sarge, and pulls in > | quantlib-ruby -- the quantlib-python package will be silently broken by the > | new libquantlib0 package that is pulled in. > In theory, yes. In practice, only the three packages I just uploaded > (quantlib-ruby, quantlib-python, rquantlib) depend on libquantlib0. > | Please rename libquantlib0 so that the package name reflects the soname of > | the library it contains (e.g., libquantlib-0.3.9). > I really do not want to do this because the soname will change for every new > upload of quantlib. This would flood the archive with meaninglessly redundant > packages I would have to run after. > Can we address this some other way? No, if you're going to provide a shared library for use by other packages in the archive, these are the rules that have to be followed. They are not arbitrary requirements; there really is no other way to properly support partial upgrades with shared library packages. Nor does changing the binary package name mean redundant packages that you have to chase after. (It's only the binary package name that should change, not the source package name.) The worst effect is that there will be a delay while the package goes through NEW processing, and this is minor nowadays. -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
