The net thing is to check the package for suitablility for upload. There are lots of things to get right, and so even experienced maintainers make mistakes.
There are lots of things to check for, and lots of ways to do it. You might also be interested in CommonPackagingMistakes.
Things to check
All packages must comply with Debian policy. The best way to do this is to become familiar with it, so that you know when you might be touching on something that is discussed there.
When you are dealing with a package that comes under one of the sub policies you should also check compliance with that.
There are many conventions used in Debian packages so that there is some consistency and it is easier to work on packages you are not familiar with. Unfortunately/Inevitably some of these are not documented somewhere like the DebianPolicy. As such it takes experience to be able to know when they apply.
Ways to check
Lintian and Linda are two package checkers that attempt to try and tell you when your package does not follow policy, or breaks a convention that is used. They are a very useful first check, and have helped eliminate many simple mistakes. However they are not perfect, and sometimes get things wrong, as well as the fact that they can't catch all mistakes.
You should really have eliminated all non-spurious lintian/linda warnings from your package before you ask anyone to look at it for you, as you will just be increasing the work for them.
pbuilder is a program that builds your package in a clean chroot, similar to that which is used on the buildds. This helps you check whther it build cleanly, and also makes sure that you have sufficient build dependencies.
Again you sure ensure that the package builds in pbuilder before asking anyone to look at the package.
piuparts is a tool that attempts to simulate installation/removal of the package, and upgrades between versions using a chroot. It can give information on which files changed, and whether anything was left behind.
It is most useful when you have mainainter scripts, or are using Conflicts/Replaces, as these are the sorts of things that are hard to get right.
If you require a sponsor for your package they will check it, but you must not rely on them to do it for you. For one thing it is enogh work to check a perfect package, without having to correct lots of mistakes. Also they will have lots of things to do, and will be more willing to sponsor you if they have less to do.
Their experience can be invaluable at spotting obscure things and solving difficult problems though.
The debian-mentors mailing list is a good way to
both find sponsors, and have a package checked. If you send a message there either with
at the start of the subject if you just want the package checking, or
[RFS] if you would like
a sponsor, then people will look at it.
It is quite common for people who are not able to sponsor to check your package first, to reduce the workload for those who are able to sponsor. Comments will be sent as replies to the list, listing problems found in your package, and pointers to more information where possible. You should listen to the comments, and don't feel insulted if there are lots of things found, people are just trying to help you. Do not be afraid to ask for more information if there is a comment made that you do not understand.
Some people prefer IRC to mailing lists. The #debian-mentors channel of irc.debian.org (oftc.net) has many of the same people as the mailing list who might be willing to check and/or sponsor the package. You might get a quicker response on IRC, and you might not get a response at all. It can also be harder to track what is going on.
Below is the checklist that I use when I am checking a package. It obviously varies depending on the package. I will use to denote the source package name, and for the version.
Download the package and unpack
- See what files are touched by the diff. Anything outside debian/ should be examined to see the changes. lsdiff -z _.diff.gz (lsdiff is in the patchutils package).
- Download the upstream tarball (look in debian/copyright if you want to know where to get it). Check if the tarball is the pristine upstream one. md5sum -.tar.gz _.orig.tar.gz
- If the request for checking was signed ensure the same key signed the email and the package, and that the signatures both verify. gpg --verify _.dsc
- Look at all files and check that all copyright/license info is recorded in debian/copyright.
- Check it is well formatted.
- Check it explains changes adequately.
- If it is a first upload the chagelog only usually contains one change.
- Check the package name and version are as expected.
- Check that distribution is unstable, and priority is low, unless there is a reason not to be.
- Check the Maintainer name and email are as expected.
- Check the date is reasonable.
- Package name matches the changelog.
- Section(s) appropriate.
- Priority appropriate.
- Maintainer as expected.
- Build-Depends etc. look appropriate. No Build-Depends on virtual package.
- Recent Standards-Version.
- Package names follow any appropriate SubPolicies.
- Architecture correct.
- Depends correct.
- Good Description and no spelling mistakes etc.
- Indented Homepage:
- Correct place to download from.
- All Copyright/Licensing information correct.
- Copyright/License statement for the Debian packaging.
- No silly code.
- Correct dependenicies.
- binary-arch/binary-indep as expected.
- Tests are run if provided.
Other files under debian/
- debian/compat a recent version.
- debian/dirs: no redundant dirs.
- debian/watch: points at the correct location, and uscan parses it.
- Builds cleanly in pbuilder.
- Nothing suspicious or odd in the build log.
- Run lintian -I -m -i .changes
- Run linda -i -t E,W,I .changes
- dpkg -c of each package looks reasonable.
- If the package is in the archive a debdiff looks ok.
- piuparts if appropriate.
Using the package
- If at all possible install and use the package.