[cctbxbb] Module versioning (was Re: Debian Package)

Picca Frédéric-Emmanuel picca at synchrotron-soleil.fr
Mon Sep 3 04:29:08 PDT 2012


On Fri, 31 Aug 2012 16:05:36 +0200
Radostan Riedel <raybuntu at googlemail.com> wrote:

> 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 <picca at synchrotron-soleil.fr>

GPG public key 1024D/A59B1171 2009-08-11
    fingerprint = 1688 A3D6 F0BD E4DF 2E6B  06AA B6A9 BA6A A59B 1171
uid  Picca Frédéric-Emmanuel <picca at debian.org>


More information about the cctbxbb mailing list