On Thu, 5 Jul 2012 10:55:24 +0200 Radostan Riedel <[email protected]> wrote:
> > I was also wondering about the C++ interface. While static libraries > > waste disk space, they could be provided in a -devel package without > > having to commit to ABI compatibility (if I understand Policy 8.3 well). > > > > On the other hand, with a real lib package, we would have to maintain > > the SONAMEs. If, as I fear, upstream won't help with this task, and this > > beeing C++, I'm afraid it could be a difficult task. > > > For ABI Compatibility we need to talk with the upstream again. My idea for now > is to make the soname versioning work with scons. That way they probably don't > need to change much on their build system but it'll be clearer for us to pack. > Problem with cctbx will be that we need a build system that builds our libs > first and uses them then to compile the python modules but we also need some > kind of method to make proper python packages. if the ABI is not stable we need to be sure that the upstream take care of the so name changed which come with ABI breakage. they need to read this [2]. if this is not the case, we can leave with private shared library. /usr/lib/cctbx look at here [1]. You can also google for debian rpath. if thoses shared library are only private. which part of the API is used by objcryst-foc. -> need to provide libxxx and libxxx-dev packages. so you are right a few of the library need to be public and we need this so numbering in their scons build system. this page gives plenty of scons recipes [3]. > Thats why I started to write a > setup.py file which imho is the best way to go here. In my last talk with the > upstream they where open for an alternative distutils build process. > But we need to figure out an easy way to submit a patch to upstream which will > as delicate as possible modify their build process so they have no argument in > rejecting our changes. definitively a setup.py is the right things to do we will use dh_python2 to build the python modules. > > > Personnally, I always used cctbx in homegrown scripts (mostly sgtbx and > > uctbx). For that kind of use, a big package is fine IMHO, as you don't > > want to spend time cherry-picking the parts you need. > But we don't want to use scripts or ENV variables ;). yes ENV variables are evils. > My thinking was just that > maybe the whole package is not always needed. I have a small django project at > work which just needs the cctbx interface. No need for mmtbx etc. > Maybe I could make a small python script to parse that libtbx_config file so > we > can automatically create this dependencies like some kind of debhelper scripts > do? An option is to create a target in the rule file which generate the control file from the _config file as you propose, but this target should be called manualy so it can be double check the same idea was proposed here [4]. it mean thaht we should propose python-xxx modules for each modules. maybe debtree[5] can help you and provide a nice picture of the packaging of cctbx and all its dependencies. > > regards > > [1] http://lists.debian.org/debian-devel/2002/07/msg02030.html [2] http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html [3] http://www.scons.org/wiki/SconsRecipes [4] http://us.generation-nt.com/answer/bug-357023-pyspf-debian-control-generated-during-build-clean-help-166422011.html [5] http://collab-maint.alioth.debian.org/debtree/ -- GPG public key 4096R/4696E015 2011-02-14 fingerprint = E92E 7E6E 9E9D A6B1 AA31 39DC 5632 906F 4696 E015 uid Picca Frédéric-Emmanuel <[email protected]> GPG public key 1024D/A59B1171 2009-08-11 fingerprint = 1688 A3D6 F0BD E4DF 2E6B 06AA B6A9 BA6A A59B 1171 uid Picca Frédéric-Emmanuel <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
