Problems found by piuparts
In the past six months, I've filed about 260 bug reports based on what
piuparts has found. About 40% of those have been fixed so far. Below is
a summary of the common problems, hopefully the list will help everyone
to find and especially avoid problems in their own packages.
* The most common problem is when postinst creates a
configuration file, log file, or some other kind of file, but
postrm fails to remove it.
* Use of ucf in postrm during a purge, without checking that ucf
is installed. Since ucf is not an essential package, postrm
during purge cannot rely on it. As it happens, I think it might
be good to have ucf (or a subset of it) as an essential package,
since this error happens a lot.
* Dropping conffiles in a newer version of a package, and not
removing it when the package is purged. For example, if the
version in sarge has a conffile, but the version in etch does
not, whoever upgrades from sarge to etch and then purges the
package is left with the file still on the filesystem. Arguably
dpkg should deal with this, but it doesn't, so maintainer
scripts need to deal with it.
* Not using debconf for prompting. There's still a few packages
that haven't switched from "echo + read" to debconf.
* Broken use of update-alternatives, which leads to alternatives
not being removed properly with the package. For example, the
name of the alternative is sometimes spelled differently in
postinst and postrm.
* Use of ">/dev/null 2>&1" in package maintainer scripts. This
hides errors from the system administrator (or your friendly
piuparts runner), and can make it quite annoying to debug what
is really going on. While there probably are a few cases where
hiding an error is OK, every time I've seen it so far, it has
been in error. Typically it seems to be used to avoid cluttering
the output with status messages or other such things during
package installation. For example, adduser can be quite chatty.
Using a --quiet option or at least only redirecting stdout, not
stderr, to /dev/null are better choices.
* Creating /usr/local/lib/foo in postinst, but not removing it
in postrm.
* Assumption that /usr/doc still exists. Or, in fact,
creating /usr/doc.
* Creating a temporary file, but then not removing it
afterwards.
* Not using invoke-rc.d to start services.
These are the more or less common problems. There are more, of course,
but they tend to unique.
Reply to: