[Debian-med-packaging] Bug#819016: jellyfish: Rename python bindings module name

[Diego M. Rodriguez]

After some more testing, I'm wondering if it would be sensible to just
*not* aim for having the python tests run during pybuild, and instead
stick to running them on a separate stage (or during autopkgtest, which
I have not ventured into yet). The main reason is that one of the tests
(swig/python/test_mer_file.py) seems not really be meant to be executed
using the standard unittest module, as it relies on a "data" variable
created during __main__(), plus some hard-coded references to files
generated during tests/swig_python.sh.

I made some attempts to running the tests during pybuild by:
* building the extension with rpath, removing it with chrpath --delete
right afterwards (kind of negating the "drop-rpath" patch temporarily):
export PYBUILD_BUILD_ARGS=build_ext --rpath "${CURDIR}/debian/tmp/usr/lib/${DEB_HOST_MULTIARCH}"
...
pybuild ...
chrpath --delete ...
* patching the tests to provide a valid value for the "data" variable
when run via unittest.
* using PYBUILD_BEFORE_TEST and PYBUILD_AFTER_TEST to generate the files
required by the test and place them in a reachable directory, cleaning
up afterwards.

While it seems doable (and probably prone to be refined), it feels
rather unorthodox and introducing some extra complexity for a seamingly
small gain - I'm still not that familiar with the package's build system
and specifics, but suspect that there are better ways to tackle this
issue, and I'd appreciate some hints or thoughts on the best course of
action.

Best regards,
-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20160325/58dc0480/attachment.sig>