Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

[Jonas Smedegaard]

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 <dr at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100608/037b758c/attachment.pgp>