On Fri, 31 Aug 2012 16:05:36 +0200
Radostan Riedel
On Fri, 31. Aug 13:31, Marcin Wojdyr wrote:
CCP4 libraries don't increase soversion as recommended in the cited sources, because it would be additional thing to do and there are many things with higher priority. IIUC the primary benefit is that a few versions of the same library can be packaged and installed at the same time. When it's needed we'll bump soversion. Note that not all projects use so-version as autotools docs recommend. For example in Qt so-version == version. There are many libraries with 0.0.0 in my /usr/lib, which is just a default value in libtool, and many projects don't increase so-version on every ABI change, because if part of the ABI is experimental and changes often the version would go up very quickly.
For Qt the version is not that much different from the so number. the API stays stable during all the Qt4 history. So the only important point is to have a stable API supported by the upstream during the life of the project.
But if you come across any practical problems (with ccp4 libs) we'll try to help. There is also this option in libtool[1]. This is pretty much what you describe with QT. I don't know about the Debian Policy here. Maybe Fred could lighten me up. This option can also be used with my proposed cctbx patch.
The problem is that even if upstream do not care about so versionning (and I can understand why), maintainer's of a shared library of all distribution can not. On the Debian side we MUST bump the so number if the binary interface changed from one version to the other. We must then change the name of the binary package of this library (libblablaN -> libblablaN+1). So the old library can be co installable with the new one (to allow a smooth transition from one version of the library to the next one). And to be co installable, the name of the library MUST be different in both package. If not both package Conflicts and it is only possible to install only one of them. So a lot's of coordination is required from the release team to do the transition (need to rebuild all the depending package and make them transition in same time to the testing distribution) So this so number is mandatory for maintainability of the shared library from the Distribution point of view. This is always welcome by third party when It comes to evaluate risk to base one of their project on another library.
I don't care if upstream is using 0.0.0 all the time. But it might happen that somebody will complain if the API/ABI compatibility breaks. Most important part of this number is "current". If ccp4 never changes the interface so 0 is fine then we shouldn't have any issues here. But in the rare case that the interface will be changed (with no backward compatibility) I'd be thankful if upstream increments this.
The important part is to easily identify if the API has changed and to
bump the so name in consequence. So this is all about coordination,
before a release we must have access to a rc version and double check
for the so bump.
Cheers
Frederic
--
GPG public key 4096R/4696E015 2011-02-14
fingerprint = E92E 7E6E 9E9D A6B1 AA31 39DC 5632 906F 4696 E015
uid Picca Frédéric-Emmanuel