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