On Mon, Jun 07, 2010 at 12:29:55PM -0400, Alexandre Quessy wrote:
Hello Jonas and the team, Here are some updates about the packaging of Scenic.2010/6/3 Jonas Smedegaard <d...@jones.dk>:Some additional packaging comments:The project includes python code. We must then follow to Debian Python Policy!Since the Python code apparently is all handled with GNU autotools I recommend to include python-autotools.mk (instead of autotools.mk), add the needed hints to debian/control, and create debian/control.in to help track CDBS-related build-dependencies.I tried to include python-autotools.mk on sid and the make check failed. To fix this would need upstream development. (I would need to change the python path in the executables and the tests cases)
Until fixed upstream (which should be doable with autotools, I believe) we can probably (depending on the exact kind of problem happening, off course) hack the hashbang after build but before doing regression tests.
Have a look at e.g. the radicale package for a routine to do such hack. And tell me if you need help ensuring that it gets applied between build and tests.
Scenic currently works with Python either 2.5 or 2.6. You just need to compile the package with the same python version that is installed, and it will run. Autotools takes care of that.
Sure - but this is Debian, not Gentoo :-) It is possible to support *both* 2.5 and 2.6 support at runtime without the user needing to recompile the package.
We provide no public module, and our project contains more C++ code than Python code. This is somewhat different from the morituri package.
Even without providing public Python modules, I imagine it would be nice to be able to use your tools with a non-default Python. If irrelevant, then change Python version hint to be "current" instead of "all" and still use python-autotools.mk (as it does some magic for Python Policy even with a single version).
Rigth now, I am not mandated by the Scenic team to change the build system, unless it's for very minor changes. Our current build system seems satisfying sor far. (we're running out of time on this project)
I do not ask you to change upstream code for this. Actually, I believe it makes best sense that you take off your upstream hat while packaging: Think in how to patch and hack the upstream code instead - and then later on take off your packaging hat and put on your upstream hat, and adopt whatever relevant of those hacks and patches for next upstream release.
I think right now we are OK with the 3.1.1 Programs Shipping Private Modules of the Debian Python policy. http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs
Quite possibly. I did not look closely...I would still recommend to use python-autotools.mk instead of autotools.mk when the code contains Python!
By the way:We should be ready to release the Scenic 0.6 version later this week. This release will contain big fixes, some found thanks to Debian sid!
Nice :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
