[cctbxbb] Debian Package

Radostan Riedel raybuntu at googlemail.com
Tue Aug 7 22:57:05 PDT 2012


On Wed, 08. Aug 01:31, Luc Bourhis wrote:
> 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.
This is not much of a choice here. In Debian packaging it's a good practice to
import the orig tarball of a release and not change the code but apply patches.
> 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?
OK to make that clear a little bit. A few patches are really only for packaging
they can't and shouldn't go back upstream.

> 0009-build-libann-statically: pending explanations
> could you explain why you need to build this one statically only?
This is also just debian specific since we already have a libann package which
would break our existing shlib for the users since you are putting additional
symbols (ann_selfinclude) into it.
> 
> 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.
This way every extension would be additionally linked by python libs as I
understand boost_adaptbx/SConscript right. This is normally not the right way.
But in gcc4.7 libsctbx_boost_python should be linked by python lib otherwise I'm
getting undefined references.
> 
> 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
We'd need an own interpreter in debian since we want to install the modules into
sys.path.
> 
> 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.
OK. Here is the problem that while automatically compiling in debian we like to
set some special linkerflags like "-Wl,-z,relro". This can change from release
to release.
> 
> 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.
OK I did not know that.

But first of all thanks for a review.

regards


More information about the cctbxbb mailing list