cctbx debian package: new commit

[Luc Bourhis]

Hi Frédéric-Emmanuel,

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

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.

>> [...] 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). [...]
> 
> So the default for Debian will be false. ok.

Exactly.

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

> Will you use pkg-config to check for most
> of the dependencies. (The boost library do not provide this pkg-config
> file)

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

That is good news!

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

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. 

Best wishes,

Luc