[cctbxbb] Debian Package

[Radostan Riedel]

On Thu, 09. Aug 03:35, Luc Bourhis wrote:
> So I had missed something indeed! This is my first experience of a Linux package in the making, you see. Unfortunately, the both of Baptiste and Frederic-Emmanuel answered my criticisms thinking they were aimed at your design of the cctbx Debian package. On the contrary, they had to be understood in the context of a installation of the cctbx by hand or using the package that CCI provides. I am afraid we talked past each other here!
> 
> Nevertheless, my thanks to Frederic-Emmanuel and Baptiste to elaborate on those patches that were only meant for packaging and that I criticised most: it is still very useful for us to understand your rationales. Some specifics:
Critics are very welcome and hopefully can help all of us. I guess we'll have
some bugs in our patching and to work with all of you will help us. Normally if
we upload a finished package into Debian (and this gets autoimported by Ubuntu
btw.) if there are any problems with it a bug report will be filled by the user
and the package maintainer will be informed. In our case we'd try to work with
you to get things fixed.
> Disk-space is not the problem I had in mind. Some people in charge of a web server are pretty paranoid about reliability and security and thus they fiercely try to minimise the number of packages installed. You may wish to consider that aspect.
Splitting the package into several small binary packages is not so complicated.
I already did it once during the packaging. To be more specific and technical, during the
build of an package we install everything in a tmp directory and then we cherry
pick everything with *.install files were we can use shell globbing etc. So we
are focused now to build everything in the first place.
> Could you provide us with the code for those, Radostan?
The method is in libtbx/SConscript:
env_etc.use_system_libs = False
def check_syslib(lib, extra_libs=None):
  """ Check if a system library is available """
  if not env_etc.use_system_libs:
    return False
  env_syslib = env_base.Clone(LIBS=extra_libs)
  conf = env_syslib.Configure()
  if not conf.CheckLib(library=lib):
    print 'Could not find %s library!'%(lib)
    conf.Finish()
    return False
  else:
    conf.Finish()
    return True
env_etc.check_syslib = check_syslib
....
if (libtbx.env.build_options.use_system_libs):
  env_etc.use_system_libs = True

The options are integrated in libtbx/env_config. I orientated on your design and 
did not change anything just add a new option.

> I guess this time you were writing about those scripts that do not wrap around python, e.g. iotbx.show_distances. For the issue at hand, there are 3 categories:
> i. those that are only useful for cctbx developers;
> ii. those that are useful to cctbx users and that are not documented;
> iii. those that are useful to cctbx users and that support the --help command line option.
> 
> For the category iii, it should be easy to generate a man page from the output of xxx --help.
> Then we should document the category ii.
> Finally, we should give you a comprehensive list of the category i, so that you can ignore them. 
This would be great.

> > In that case as explained by Radostan, Debian need to tune the build
> > process by providing their own build flags. The trade-off would be to
> > add a config flag that should allow or not to use the LDFLAGS
> > --use-also-LDFLAGS
> 
> Indeed.
> 
> > what is your opinion ?
> 
> Nat? What do you think of this issue?
I can prepare a patch for this.

> > If not our last solution is to compile it statically for now.
> 
> 
> I reckon you should just do that indeed, as that hack is very important to make the CIF parser usable on large structures.
OK, I'll delete the packaging patch. If I remember correctly antlr3 in cctbx is not build as a shlib so we do not need to change anything
here.

> Now about the support of distools. Even though as we both agree this code is totally orthogonal to our existing base code, this is no small patch and it will go upstream and we will therefore need to maintain it. Hence my scrutiny. So thanks for your detailed explanations that will save me some time reading your code.
We can always collaborate in maintaining the code.

> Could you elaborate? As that sounds like a bug we should fix.
I don't remember exactly but after building libscitbx_boost_python
debian has a helper script dhshlibs which checks for unnecessary linking etc.
I saw some unreferenced symbols which pointed to a missing python_lib during linking.
I'm going to fire up a build without that patch later to give you the specifics.

> Ok, thanks for the clarification. We will concentrate our scrutiny on those then.
It's a pleasure to work with all of you together on this.

kind regards
Radi