[I am Cc:ing this message to debian-release; perhaps the release folks will have some helpful comment on this.]
In the process of preparing the 3.1.0-1 release of libsuitesparse, I noticed a serious problem regarding the soversion numbers of the libraries shipped in this package. The soversion numbers are not determined by the upstream authors and they have been arbitrarily set to 1.2 in version 3.0.0 of libsuitesparse (e.g. libcolamd.so.1.2). When Daniel Rus Morales committed the changes for 3.1.0 in December, he changed all the soversion numbers such that they match the version number appearing in the */Lib/README.txt files (e.g. libcolamd.so.2.7.1) Although this practice is highly discouraged [1], I think there are no many other options left to us. Choosing the soversion number is somewhat tricky and a relative good understanding of the upstream changes is needed [2]. Finally, it is not our job as packagers to do it, it's upstream's. [1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi [2] http://sourceware.org/autobook/autobook/autobook_91.html#SEC91 Now, the idea of changing the soversion numbers for each release of libsuitesparse is okay, in principle, but yields problems. Let us consider, for instance, the version of suitesparse currently in SVN. It produces a library file libcolamd.s0.2.7.1. If we uploaded this version to unstable, the users would get it installed in the next upgrade and then she would have problems like this: $ lp_solve -max -mps /var/tmp/model.mps lp_solve: error while loading shared libraries: libcolamd.so.1: cannot open shared object file: No such file or directory This happens because libcolamd.so.1.2 would be inadvertently replaced by libcolamd.so.2.7.1 in libsuitesparse 3.1.0-1. This is patently wrong. As I wrote above, it will be a huge burden for us to properly take care of soversion numbers. Furthermore, the fact that the package ships with separate components, each one neeeding its own soversioning, complicates the problem. Hence, splitting libsuitesparse into separate packages (e.g. libcolamd2, libcholmod5, etc) will not help us, because the soversioning burden would remain. I propose then to adopt the following solution, which is quite ugly but should work. Let us create a new library package called libsuitesparse-3.1.0 (I am not sure we should also have a new source package named, say, suitesparse-3.1.0). In this package, we include all the libraries with soversion numbers superior to so.1, which was the number chosen in libsuitesparse_3.0.0. We must have, at least, lib*.so.2.* files, such that the libsuitesparse-3.1.0 will not conflict with the libsuitesparse package currently in unstable/testing. This solution is ugly for two reasons, at least. First, we will have to create a new package for every new upstream version. Second, even if there will be no changes in the libraries' API and ABI, we will force all of the reverse-dependent packages to be rebuilt in order to use the new version. Anyway, I do not see another simple and efficient way to cope with the problem. I am open to other suggestions though. If there are no objections to my proposal, I will go ahead, make the necessary changes in SVN, and upload the new package to experimental. Remember that the soft freeze for lenny will happen soon [3]. We should then hurry up with this, because it will involve a dormant period in the NEW queue, besides the fact that suitesparse is a main knot in the complex g77 -> gfortran migration [4]. [3] http://lists.debian.org/debian-devel-announce/2008/02/msg00002.html [4] http://wiki.debian.org/GfortranTransition -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
