Tips
2849
Comment:
|
2811
un-CategoryDocumentation-ise
|
Deletions are marked like this. | Additions are marked like this. |
Line 51: | Line 51: |
["CategoryMOTU"] CategoryDocumentation CategoryCleanup | ["CategoryMOTU"] |
The page intends to list tips to do a proper review and don't miss common bugs. It can give some hints how to review packages e.g. on [:REVU]
[http://people.debian.org/~mpalmer/sponsorship_checklist.html Some suggestions from Debian ]
[http://ftp-master.debian.org/REJECT-FAQ.html Some more suggestions from Debian (this time from the FTP masters instead of a random maintainer)]
Same version, new revision
If you review another revision of an existing package, be sure to have a copy of the old version around.
# get source of new version mkdir orig; cd orig; apt-get source <package>; cd .. debdiff orig/<package>_old-version.dsc <package>_new-version.dsc | less
This should give a nice overview of what changed, make notes of what to double check or ask the maintainer.
Thing always to do
Always check
head -n1 debian/changelog to have the correct release target.
If debian/rules changed, ask the maintainer, what he intended to do.
Make sure the original tarballs are the same (md5sum(1)).
Use interdiff(1) (patchutils package) against the .diff.gz, and debdiff(1) (devscripts package) against your test-built binary packages to examine what you've changed (and ensure it tallies with what you expected to change).
- Use filterdiff to exclude generated or annoying parts
Check if debian/copyright is correct, acurate and complete.
See http://lists.debian.org/debian-devel-announce/2003/12/msg00007.html and http://lists.debian.org/debian-legal/2003/12/msg00194.html
- If a package uses several licences, list which file is under which licence
- Always make sure it is clean, who the copyright holder is, and the year of copyright
- Check for unuseful comments (e.g. autogenerated # dh_X in debian/rules) in scripts
Build test
Before building the package, check debian/rules and the Makefile, to be sure the package doesn't install into /usr.
When testing if the package builds, it is useful to run debuild -S again after debuild, and check the diff for files not cleaned during debuild. The only files in the diff after that should be debian/*.
After it's built
If you built the package (PbuilderHowto), install it and
check /var/lib/dpkg/info/<package>.list if everything is in the right place
do apt-cache show <package> to check changed dependencies
- run lintian on the resulting debs.
REVU Reviewing
To faciliate reviewing in [:REVU], you can ask any REVU Admin to do a revu-build as described here: http://revu.tauware.de/cgi-bin/trac.cgi/wiki/Revu1Building.
["CategoryMOTU"]
MOTU/Packages/Reviewing/Tips (last edited 2008-08-06 16:27:26 by localhost)