Thoughts on creating better RPMs

Despite the impression given from endless flame wars about the merits of Debian packages vs RPMs, the biggest problems with RPM are not technical, but rather quality control. With its very long release cycles, extensive / comprehensive testing, and higher than average ability of its maintainers, the debian packages one encounters are very well produced indeed. Somewhat a victim of its own success & popularity, RPMs are being produced by a large number of third parties, many of whom only have passing familiarity with Linux, let along RPM packaging guideliens. As an unfortunate result, there are a large number of poorly packaged RPMs floating around the net. The even more unfortunate thing is that if just a few simple guidelines were followed, the situation would improve dramatically. So, without further ado, here are some pointers.

Group names

Only use group names which are defined in /usr/share/doc/rpm-[VERSION]/GROUPS – don’t make up new groups

Installation prefix

Most software should install into the regular /usr hierarchy, and definitely not into /usr/local, or /usr/local/[APP] which are for *unpackaged* software. Since RPM manages all installed files, there is no need to worry about files from different apps being installed side-by-side. RPM knows what belongs to which app and will ensure clean uninstallation of all files, and prevent installation of two apps with conflicting files. If a private installation location is required, then use /opt/APP-NAME/VERSION, which both separates out the app into its own heirarchy & also allows multiple versions to live in harmony.

Files list

The %files section MUST list all files belonging to the application. RPM uses this files list for many purposes

• to ensure that two applications don’t try to install the same file
• to ensure complete removal of all files upon uninstallation
• to verify installed files for changes, from modification time, and ownership right down to md5 sums.

Having a %post section which, for example, extracts a ZIP / tar.gz archive of files for the application completely bypasses these important features of RPM, dramatically lowering the value of having the application packaged in an RPM at all.

Init scripts

If the application includes init scripts, make sure they are registered with chkconfig, but don’t turn on the service by default – policy decisions such as whether a daemon should start on boot are the realm of the system administrator, not the software distributor. This is especially important if the application listens on any network ports.

Patch releases

After an initial release of software it may be neccessary to distribute a patch update. The approach for this is to take the original source RPM, add one or more patches in the spec file, increment the release number & then rebuild the bina4ry RPM.