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

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


On Sat, 1 Sep 2012 11:35:04 +0200
Radostan Riedel <raybuntu at googlemail.com> wrote:


Hello, I cam back from longer holidays that I expected :). It is always good ;)

> > 1. Each and every cctbx developer becomes aware of so-versioning. Let's say a module is at 2.3.4, so we have
> > 	env.SetVersionInfo(vers="2.3.4")
> > and then a change is made to the C++ code. The developer responsible for that change should then figure out the new c.r.a and then add a comment
> > 	env.SetVersionInfo(vers="2.3.4", #next release# vers="c.r.a")
> > It would then be easy to automate an edit en-masse before release that would change that line and all its sisters to
> > 	env.SetVersionInfo(vers="c.r.a")
> > That's basically a formalised version of your proposition in your answer to Johan earlier.
> > 
> > 2. Cctbx developers would not care about so-versioning and before a Debian release, the cctbx Debian maintainers would go through each call to SetVersionInfo to set the right c.r.a, based on a careful examination of the commits, complemented by asking questions to the core cctbx developers (or simply open questions on this forum).
> I'd of course like the first extreme better. For starters  it would be great if
> everyone feels responsible for the "current" number. I'm not a c++ developer and
> I don't know if thats easy?


To my opinion the first solution whould be the best one also for other
distribution. Indeed this is a "social" problem, developpers of the C++
librarty should learn about ABI/API compatibility like expected by most
distributions when it comes to do some "long term" support into an
integrated environment. The person who did the change is the only one
which know the implication of the changes.

Now during the build of a Debian package we have some tools that could
detect API modifications and the build can fail if a library without a
so number bump, remove a symbols.

So it is a round trip collaboration, we can check if a so bump is
requiere by a build of the futur next stable release, Identify the
problem and explain to the person in charge of the C++ library how to
modify the corresponding so number. After a few roundtrip (release) I
think that peoples whould understand how to deal with thoses numbers.


> 
> > There are relatively very few shlibs compared to Python modules. Keeping track of the version of all of the latter by hand would be an enormous amount of work. I don't think we can get it done cheaply with some automatic keyword expansion if we want proper major.minor.patch or worse something as involved as so-versioning.
> Maybe it can be good to look on other projects how they are doing this. As a
> python developer I'm always expecting different API's when it comes to new
> upstream versions. I checked the policy for Debian and there seems to be nothing
> special in versioning extensions and modules. Maybe Justin can tell us something
> about Gentoo. I'd say we don't need to worry about it for now.

Yes excepted if you distribut python extension used by other third
party to build other extension. A good example is the python-numpy
package. It was a nightmare for distribution before they introduce an
API and ABI number.
the public C API/ABI of this extension is now following a sort of so
number and when someone build a package relying on this python-numpy
extension the dh_numpy helper generate the right binay dependencies,
based on the ABI number maintained by the numpy upstream.

there is a dependency on python-numpy-abix. Exemple for the scipy package

Package: python-scipy
Version: 0.10.1+dfsg1-4
Installed-Size: 34405
Maintainer: Debian Python Modules Team <python-modules-team at lists.alioth.debian.org>
Architecture: i386
Provides: python2.6-scipy, python2.7-scipy
Depends: python-numpy (>= 1:1.6.1), python-numpy-abi9, python (>= 2.6.6-7~), python (<< 2.8), libamd2.2.0 (>= 1:3.4.0), libblas3 | libblas.so.3 | libatlas3-base, libc6 (>= 2.3.6-6~), libgcc1 (>= 1:4.1.1), libgfortran3 (>= 4.6), liblapack3 | liblapack.so.3 | libatlas3-base, libquadmath0 (>= 4.6), libstdc++6 (>= 4.1.1), libumfpack5.4.0 (>= 1:3.4.0)
Recommends: g++ | c++-compiler, python-dev, python-imaging


So the same think should be proposed if third party package rely on C
python extension of cctbx. But indeed it mean, you need to care about
the versionning of your public C API/ABI.


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