[Neurodebian-devel] Debian packages for Stimfit

[Christoph Schmidt-Hieber]

Hi Yaroslav,

thanks for all the recommendations, they make a lot of sense. I'll implement them as soon as possible.

Best,
Christoph

On Mon, 24 Jan 2011, Yaroslav Halchenko wrote:

>
> On Mon, 24 Jan 2011, Christoph Schmidt-Hieber wrote:
>> Unfortunately, stimfit has a rather unusual structure that I'm not too happy with: "libstimfit" is not really a library in the sense that it could be used by anyone else. In fact, it's the full program that I had to split into a separate library so that it can be imported into the Python shell at runtime. If you wish, it's everything except of main().
>> Now the problem is that I haven't found an elegant way to make the autotools chain understand that. At the moment, I'm linking explicitly during install (L27 in src/stfswig/Makefile.am)
>
>> 	ln -f ${prefix}/lib/${STF_PYTHON_LIBNAME} ${PYTHON_SITE_PKG}/stimfit/_stf.so
>
>> This hard links libstf.so.0.0.0 to _stf.so so that the Python shell can communicate with the running program.
>
> thanks for the explanation -- it makes things clearer ;-)
> since this library is not intended to be public, it better be hidden.
> according to
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
> ,---
> | 8.2 Shared library support files
> | It is recommended that supporting files and run-time support programs
> | that do not need to be invoked manually by users, but are nevertheless
> | required for the package to function, be placed (if they are binary) in
> | a subdirectory of /usr/lib, preferably under /usr/lib/package-name.
> `---
> thus logical location for it /usr/lib/stimfit  and both executable
> stimfit and python extensions should be linked against it under coming
> from that directory
>
> if you
> ls -l /usr/lib/*/*.so
> you will see plentiful of other packages doing the same
>
> I guess the easiest solution is by providing -rpath to the linker and
> since it is not public -- version is not per se needed, thus something
> like
>
> -Wl,-rpath,${prefix}/lib/aeskulap -avoid-version
>
> in your configure.in
>
>> I would suppose that this is why dh_shlibdeps complains about all these missing symbols because it is not aware of _stf.so?
> probably ;-)
>
>> This being said, the deb seems to run and install fine on current Ubuntu and Debian installs.
> that is great -- but you do want to make build more robust and
> standardized, right? ;-)
>
>> One thing that I would like to add to the deb is the pure-python
>>  stfio module. How would I add this to the deb? Create a new
>> control/rules/etc. directory? Or add a package to the existing files?
>
> you can build as many binary packages as you like from a single source
> package, i.e. debian/control can contain many 'Package: ' entries, in
> this case it should be python-stfio, Architecture: all (if it is
> pure-python without extensions).  then, after things are built, unless
> they get installed directly into debian/binarypackagename/,
> usually they get placed under debian/tmp and you direct which things go
> to which binary packages by creating debian/binarypackagename.install
> files and (unless possible easily with .install files) - by moving
> things into corresponding debian/binarypackagename/ subdirectories
> within debian/rules.
>
> just look into some package for how things done... e.g. libfann of
> Christian seems to be clean enough, so
>
> apt-get source libfann2
>
> and see how things are sorted out
>
>