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

Jonas Smedegaard dr at jones.dk
Wed Jun 2 22:06:15 UTC 2010


After a nice meal I now have some comments on your packaging:

First of all: Please package using git-buildpackage and upload to the 
pkg-multimedia repository - more info here: 
http://wiki.debian.org/DebianMultimedia/DevelopPackaging

When you have switched to Git, then add Vcs-Git and Vcs-Browser stanzas 
to the control file.

Set the Multimedia team as Maintainer and yourself as Uploader (yeah, 
technically you cannot upload, but in this team we use that field as a 
hint of whom is mainly working on the package).

Long descriptions should be line-wrapped at 72 chars.

Avoid stray spaces at end of lines (noticed in long description, but 
should be avoided everywhere).

Your Suggests: seem odd: do the project really make direct use of those 
tools?  If it is just that you happen to find those tools nice to have 
installed on same hosts as you use this project, then I suspect they 
should simply be dropped, or alternatively (but I find it a bad style) 
in a separate metapackage depending on the actual project package and 
those add-ons that you find relevant to have installed together.

There are no packages in Debian named linux-rt or linux-headers-rt.  
Please package for Debian, and then secondary - if needed - adjust for 
derived distributions like Ubuntu using alternative Git branches.

You have some commented out dependency lines in the control file.  It 
works, but is bad style IMO.  When using CDBS, you can instead declare 
dependencies in the rules file, allowing both commenting out, grouping 
of relations with added explanatory comments, and conditional relations 
(e.g. arch-dependent or when compiling with a certain build flag set).  
See e.g. the morituri package for an example of this.

Please use recursively expanded variables in the rules file whenever 
possible.  That is, instead of := use = which mean the content gets 
resolved when used rather than when read by make.  In most cases there 
are no differences but in some cases there are, which can cause 
surprises if unaware of the differences.

It is bad style to invoke dh_install again (in addition to the included 
debhelper.mk snippet).  Instead either add a debian/scenic.install 
file, or set DEB_DH_INSTALL_ARGS.

Are you sure you need to build-depend on bash-completion?

The binary package is arch: any, but the configure.ac checks for 
linux/videodev2.h which I suspect means that the package will only 
succesfully compile on Linux architectures.  If correct, then the best 
would probably be to fix it upstream to avoid Linux-specific parts when 
on non-linux archs, or alternatively to tighten to package only on Linux 
archs.

Either json or simplejson is used upstream.  Are you aware that those 
implementations are not fully interchangeable (one of them - I forgot 
which - do not follow JSON specs!), and they might be slow too?  The 
Sugar project switched to python-cjson for these reasons.

It seems some subprojects provide regression tests.  If usable then 
please enable them.  Most elegant approach - if workable - is to set 
DEB_MAKE_CHECK_TARGET = check .

Have a look at e.g. morituri package for some modern CDBS enhancements - 
like upstream tarball processing, and copyright and licensing tracking.


Please don't hesitate to ask if any of this is not clear to understand 
for you.


Kind regards,

 - 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/20100603/38ec96e4/attachment.pgp>


More information about the pkg-multimedia-maintainers mailing list