QA for RPMS/Reviewing RPM Spec Files

From openSUSE

Quality Assurance for Your Newly Built RPMs (DRAFT)

This document tries to outline some steps and concepts for making higher quality, more reliable rpms, along with some guidelines on how to review other's packages. As a packager, you have responsibility to try to do things "the right way." Essentially, when someone installs your package, they are giving you root permissions on their machine and with that comes the responsibility to not break things and/or cause problems for them later on. Part of this is related to the Trust Concept

Pre Build checks

• Check for source tarball md5sums, sha1sums or gpg signatures from the project home page. This is a welcome practice by upstream. If you are a developer on an open source project you should encourage this practice. If none are posted by upstream you can contact the developers or project release manager and ask them to add these to future releases.
• Open the source tarball and check for correct licensing and other docs. Is a man page included ? Lack of a man page is considered a blocker for Debian and it is not terribly hard to create one to submit upstream.

Build Checks

• Run rpmlint from the command line on your packages. Rpmlint is not perfect, but makes many sanity checks on your rpms. Strongly recommended.

   rpmlint package.arch.rpm 

  will give you a report on your package will be issued. The -i switch will give more verbose and detailed output.

Install Checks

• Use rpm's debug output to see every change made by an install.

rpm -ivvh package-x-x.rpm 

rpm -Uvvh package-x-x.rpm