[cctbxbb] Debian Package

Luc Bourhis luc_j_bourhis at mac.com
Tue Aug 7 16:31:14 PDT 2012


Dear Radostan,

I appreciate the effort of yours. Making the cctbx installable with aptitude is great indeed. Then, as you mentioned, it would be great if it became installable with yum on Fedora-like system, etc. Making it installable with distutils may open the possibility to use easy_install or pip to install the cctbx. More of a gimmick imho but the average Python user seems to expect that these days.

First a general comment: you have been using git in a manner that I find suboptimal. It would have been much easier for us (and much more in the spirit of git) if you had asked us to make a public git repository (I exclusively work with git for the record, using git svn to interact with sourceforge, so I could have provided one on no time), and then forked it. Indeed we would have been able to simply check out your repo into a branch of our public repo, and then immediately test your changes, and eventually apply those that passes the trial of fire. Actually, as pointed out in my comments below, we can't even apply your patches because some seem to be missing.

Here is a review of the patches you propose. When I write "accepted" or "rejected", those are of course propositions as the final decision has to be collegial in this new era for the cctbx.

0001-remove-hardcoded-libtbx_build-env: accepted
No problem on our side. You want to do that so as to be able to run cctbx-based script without /usr/bin/python instead of our wrappers like libtbx.python. Fair enough.

0002-fix-opengl-header-missing-gltbx: rejected
Do you really want to force all cctbx users to install OpenGL? Even if they don't need it because e.g. they run cctbx-based scripts as the back end of a web server?

0003-correct-paths-in-dispatcher-creation,
0008-Fix-to-skip-pycbf-build,
0016-adapt-test_utils-in-libtbx-for-setup_py-test,
0018-Fix-to-use-systems-include-path,
0019-Fix-to-skip-build-of-clipper-examples
I have put those together because they participate to the same philosophy. They make sense only in the Debian environment you are designing, where the cctbx will depend on other packages, that will therefore be installed in standard locations if the cctbx is installed. But in agnostic an environment, where the cctbx dynamic libraries and Python modules are not in standard places, those patches break the build system and part of the runtime system. 
For example, 0018 assumes there is gpp4/ccp4 somewhere on the header paths: that would require changing the packaging of Phenix to match that. This is so obvious that you can't have missed that. So am I missing something here?

0004-upstream-fix-for-declaration-errors-in-gcc4.7: already done
This is Marat's fix in our trunk at rev 15462. 

0005-fix-for-gcc4.7-compilation-error: already done
This is the fix of mine in our trunk at rev 15576.

0006-options-for-system-libs-installtarget-and-prefix: needs thorough testing
I approve the spirit of it but this patch introduces a truckload of changes and that needs to stand the trial of our nightly tests.
Note that you use a couple of new methods, e.g. env_etc.check_syslib, that none of the patches define as far as I can tell.

0007-adding-shlib-versioning: accepted
The new build option libtoolize seems properly introduced. Beyond that I must admit I am rather clueless about libtool.
Anyway, if configure is not run with --libtoolize, this won't impact us!

0009-build-libann-statically: pending explanations
could you explain why you need to build this one statically only?

0010-adding-setup_py: pending discussions
I don't quite understand your code but this is orthogonal to our existing code. What do you need class build_py for e.g.?

0011-fix-missing-python-lib-during-linking: needs tidying up
Why don't you append to env_etc.libs_python instead of created the string env_etc.py_lib? We try to use list as much as possible in the SConscript.

0012-fix-to-remove-cctbx.python-interpreter: rationale? And trunk has moved on anyway
Why do you need to remove cctbx.python?
uc1_2_reeke.py has been removed and there is now uc1_2_a.py that features cctbx.python too

0013-fix-to-support-LDFLAGS-in-use_enviroment_flags: not sure
This seems done in orthodox a manner. However, this has the potential of wrecking havoc to Phenix on some machines where LDFLAGS is set in fancy ways.

0014-Fix-to-append-CPPFLAGS-to-CXXFLAGS: rejected
CPPFLAGS is added to CCFLAGS which is eventually used for the both of C and C++ by SCons. This patch is therefore incorrect.

0015-fix-cif-parser-to-work-with-antlr3c-3.2: for Richard's eyes
Richard (Gildea) is the expert when it comes to ANTLR

0017-autogenerate-pkgconfig-files: accepted
Your business!

Best wishes,

Luc




More information about the cctbxbb mailing list