I wrote piuparts, a package installation, upgrading, and removal
testing tool, in June, and have been running it over etch since.
Most packages succeed, and many that fail do so because something
they depend on fails. (If piuparts notices a file left behind on the
filesystem that dpkg did not know about, it cannot know which
package was the cause. Or at least I've been too lazy to implement
such logic.)
My approach has been to analyze failures, figure out what the root
cause is, report a bug, and then add suitable --ignore or
--ignore-regex options to simulate a fix.
I still have about a thousand failed logs to process, and this is
going to take a while. There are, however, some patterns emerging
and I thought it might be useful to report on them now rather than
at some distant future date when I can run piuparts on the entire
etch without unignored errors.
* Unconditional use of non-essential packages in postrm when a
package is purged (policy, 7.2, description of Depends). One
of the most common reasons is because the package uses ucf.
* Files created in postinst, but not removed when package is
purged. For example, log files (policy, 10.8), or
configuration files made from a template of some sort.
* Temporary files created, but not removed by maintainer
scripts.
* Complicated alternatives setups, where some are not un-done
when package is removed.
* Running programs in postinst that automatically create a dot
file in the user's home directory. This puts files into
/root, which is potentially troublesome in other ways than
just leaving cruft on the filesystem.
* Various scripting errors, such as using "set -e" and then
"foo && bar" instead of "if foo; then bar; fi".
* Some packages still don't use debconf for prompting, and
instead do silly stuff that assumed it is OK to read and
write /dev/tty.
Most of the errors I find are pretty trivial, just minor oversights,
and mostly harmless cruft. Happily, this also means they are easy to
fix.
Reading piuparts logs en masse is tedious and I would be extremely
happy if all developers did it for their own packages. Go ahead,
please prevent me from becoming a top ten bug reporter. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
