cctbx debian package: new commit

[PICCA Frédéric-Emmanuel]

> I met Marcin Wojdyr. He is currently in charge of the CCP4 releases and therefore definitively the guy with whom you should get in touch.

thanks, we will set up a wiki page also for ccp4 and see how things are going on. I will check with DebiChem if other are interest in the ccp4 packaging.

> Is this option check
> nevertheless for the right dependencies and just do the update depending
> on the value of the options.

I am afraid I don't understand the question.

ok you answer my question :) with the next paragraph.

> The current plan is to make it purely cctbx-specific. The check will only scan the directories one level up from cctbx_build where external dependencies are supposed to be according to our scheme. Hence the "no" > option, so that it does not interfere with your work. I believe it's better to keep it orthogonal as that new configure feature is only aimed at cctbx developers who are most likely to want the latest Boost, SCons, and > in the future CCP4 (latest as blessed by the core developers which is the whole point of that new feature).

The good news for you is that the version we bless will be clearly written in a configuration file of ours, so you won't have to guess.

so you need to decides of supported OS (RHEL 5,6 etc, Debian/Ubuntu,) and check for the available library boost etc...
This way you can decided of the minimum supported version without to much work.

for the Debian packaging the release period is 2/3 years and deciding to stick with the stable version is most of the time a good decision :)
this way it is possible to provide what we call backport for peoples which need lastest vesion of cctbx.

If at the end we had no more Debian specific patch and only a python module. backporting cctbx for the current Debian  stable will not be a huge workload.

> > 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>/*.

> That is good news!

This should be easy with a pure setup.py build script, if would be completly free :)

> Definitively. The 100% bullet proof way to spot them all is to read all the "run_tests.py" scripts. Each and every test starts with the prefix "tst_" which provides another way. Most of them are in directories named "tests" but not all, so don't rely on that.

In fact thoses c++ test program are not compatible with a pure distutil script. Indeed we need to build the C++ library to generate all the C++ test program.
So we need to figure it out how to instakll thoses private C++ library.

ok.


cheers


Frederic