Hi Steve, Thanks for your thorough comments. I am not going to reply to all of them because I think there is a misunderstanding here:
* Steve Langasek <[EMAIL PROTECTED]> [2008-02-09 10:53]: > On Mon, Feb 04, 2008 at 02:42:29PM +0100, Rafael Laboissiere wrote: > > 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 don't understand what "burden" you're referring to. You're packaging > libraries -- it's your responsibility to keep track of soname changes > upstream and make sure these are reflected in the package names. > > It's not your responsibility as a maintainer to make sure that upstream's > soname changes are appropriate, though in practice you should find out soon > enough from users when an soname bump has been missed. The problem with SuiteSparse is that the upstream author does not specify the sonames at all. The original makefiles only build the static libraries. We patched the Debian package in order to build the shared libraries and the sonames are chosen by us in a quite arbitrary manner. Anyway, in the afterthought I am not convinced the solution I implemented in libsuitesparse-3.1.0 (namely by naming all librairies lib*.so.3.1.0) is appropriate. If we followed my proposed scheme, when upstream will release, say, SuiteSparse 3.2.0, then the libraries would be named lib*.so.3.2.0, which will not necessarily work since the sonames will be kept the same (lib*.so.3). At any rate, I am happy I released libsuitesparse-3.1.0 to experimental and not to unstable; we still have some flexibility to fix the eventual problems. The royal way to cope with this problem is, as Daniel Rus Morales already proposed, to convince the upstream author to specify the soversion numbers in the upstream Makefiles. A sub-optimal solution would be to carefully specify the soversion numbers ourselves. This is the "burden" I was referring to. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
