Re: Library soversion numbers in SuiteSparse
Hi Rafael,
On Mon, Feb 04, 2008 at 02:42:29PM +0100, Rafael Laboissiere wrote:
> [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).
In fact, the sonames are all $lib.so.1, not $lib.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.
> 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.
But this, then, is a problem of your packaging, not of upstream's renaming.
Why do you have a large number of libraries, all shipped in a single,
unversioned binary package? Why have you not changed the binary package
name in step with the soname changes? *Any* time your library's ABI changes
incompatibly (and an soname change is, per se, an ABI change), the package
name should also be changed. If the result is that it has to conflict with
the previous package because only some of the packaged libraries have had
soname changes, that's unfortunate, but it's a direct consequence of
packaging the libraries together when their sonames are not guaranteed to
change in lockstep.
> 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.
> 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.
What do you propose to do with any libraries whose sonames *don't* change
between upstream versions? You can't ship just those libraries under the
old package name, because the old package name implies that all of the old
libraries are present and usable. If you ship them under your new package
name, you have to conflict.
This is why libraries that are not maintained in lockstep should have their
own binary packages for each.
> 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.
Forcing the reverse-depends to rebuild is much better than keeping multiple
old copies of the library around in the archive for no reason.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: