[cctbxbb] Debian Package

[Radostan Riedel]

On Thu, 30. Aug 13:18, Marcin Wojdyr wrote:
> I've setup OBS repository (to evaluate usefulness of OBS) with a few
> ccp4 libraries, only RPMs for now:
> https://build.opensuse.org/project/show?project=home:wojdyr:ccp4
> It's a really nice service, user's interface looks like this
> (superpose is a small program, part of the ssm library):
> http://software.opensuse.org/download?project=home:wojdyr:ccp4&package=superpose
> I'd like to add also debian packages there, but I have less experience
> with debs, so I'll wait until you guys make packages for Debian and
> then I'll copy it.
It's really a nice service and you're welcome to do so when I manage to pack them.
> 
> Regarding forked versions of mmdb and libccp4: Eugene actively
> maintains mmdb and fixes bugs from time to time, so it's better to
> take it directly from us. gpp4 is a fork of a subset of libccp4 (maybe
> it was forked before libccp4 was separated from the ccp4 codebase),
> but the difference is not big. libccp4 requires another additional
> dependency, ccif, but it can be avoided using --disable-ccif (ccif is
> not needed for cctbx and coot).
> AFAIK coot works fine with the latest versions of the libraries and
> the versions in cctbx are updated nightly from our repositories.
It's always better to use the original software I guess. 
To package a software we need a good build system like GNU Autotools.
How are the packages distributed? Can I download libccp4, libmmdb, libssm as
standalone packages? Is there a proper versioning of the packages and so-versioning? 
If this is guaranteed I guess it shouldn't be too hard to package them from scratch.

> 
> And a question about so-versions: is it a formal requirement for
> Debian packages? What will be the initial so-version of cctbx? 0.0.0?
It's not well seen to package a shared library without so-versioning.
I can imagine some developers building software based on a shlib without versioning and in a 
few years upstream might change the API and this leads to weird errors during runtime and nobody knows why.

About the version number this is something upstream needs to decide. From libtools manual[1]:

current:revision:age
"""
    Start with version information of `0:0:0' for each libtool library.
    Update the version information only immediately before a public release of your software. More frequent updates are unnecessary, and only guarantee that the current interface number gets larger faster.
    If the library source code has changed at all since the last update, then increment revision (`c:r:a' becomes `c:r+1:a').
    If any interfaces have been added, removed, or changed since the last update, increment current, and set revision to 0.
    If any interfaces have been added since the last public release, then increment age.
    If any interfaces have been removed since the last public release, then set age to 0. 
"""

BTW: Would it be possible to unbundle cctbx and distribute it seperately for people who have the shlibs already.
In GNU Autotools you can do a check for a library and interrupt if it's missing. 
I'm thinking of something like this: cctbx_2012.08.30.src.tar.gz


[1] http://www.nondot.org/sabre/Mirrored/libtool-2.1a/libtool_6.html