cctbx debian package: new commit

[picca]

Luc Bourhis <luc_j_bourhis at mac.com> writes:

> Hi Frederic,

Hello Luc

> I apologise for not having done it yet. I will update the wiki this week.

No problem we are working when we can :)

> Now onto the meeting we had in Cambridge after the Phenix
> workshop. Nat was adamant to use upstream CCP4 instead of the patched
> version we currently rely on and he and Marcin started to look at how
> and when to push the Phenix patches upstream. So good news on that
> front.

Great news, now we need to work also on the ccp4 packaging. did you met
peoples from ccp4 at this meeting. We need some entry point for this
huge library/software bundle.


> Onto another subject altogether, we have also decided to add a new
> option to libtbx/configure.py to automatically check whether the
> external dependencies are installed and with the right version and if
> not to warn the user and then install them:
> --update-external-dependencies=(no|ask|yes). We basically had enough
> of the bug reports boiling down to the wrong version of Boost (and a
> few years ago it used to be SCons) and it will get worse when the CCP4
> will be another external dependency. The default will be yes, so
> that's one thing to keep in mind when you will build the Debian
> port. This new feature is not coded yet but it should be done within a
> month.

So the default for Debian will be false. ok. Is this option check
nevertheless for the right dependencies and just do the update depending
on the value of the options.  Will you use pkg-config to check for most
of the dependencies. (The boost library do not provide this pkg-config
file)

> Finally, the thorny subject: shlibs versioning. The reaction was lukewarm to be honest.

Yes it is a big amount of work. Also for us as maintainer.

> The key problem is that everybody felt that those shlibs are just an
> implementation detail of the cctbx, to avoid recompiling the same
> code. For example, libiotbx_pdb.so is linked into the Boost Python
> extension iotbx_pdb_ext.so that is to be used from Python script and
> the pure C++ program Phaser as a trick to avoid recompiling all the
> iotbx/pdb/*.cpp files. We see it as a trick because it does not work
> in the large: most of the cctbx C++ code heavily uses template
> functions and classes and it is therefore header-only. A C++ developer
> must and only need to include the relevant headers in his code. The
> implementation-detail aspect is nicely illustrated if we were to make
> one key class of e.g eltbx into a template: this could result in
> pulling all eltbx/*.cpp from libcctbx.so.
>
> So basically, we are not kin on promoting the use of those shared
> libraries. Thus is there a way to declare shared libraries as private
> to a port in Debian?

Ok, I think that it is possible to made thoses library private.
I need to check for this. Usually this is achived by putting the private
libraries, in /usr/lib/<package>/*. We need to check how all this deal
with the multi-arch. The good news is that reduce the number of binary
package to a few.

python-cctbx
python-cctbx-dbg

It would be nice to have also a package with the test program. This
would help when reporting bug report.

Thanks, for your help, and thanks for the wiki update.
This are great news :)

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>