How not to package software in RPMs

August 27, 2005

I spent today wrestling various pieces of commercial software into our Fedora Core 4 auto-install environment. In theory this should have been fast and dirt simple, because all of the vendors had things packed up in RPMs.

In practice, most vendors produce RPMs that are glowing examples of how not to package your software in RPM form. Instead of creating RPMs that are fully installed software, they generally create RPMs that are little more than lightly packaged up files and then add huge amounts of post-install scripts to shuffle everything around.

Pride of place has to go to the Sun JDK RPM, which:

  • does not even ship as an RPM; instead it ships as a shell script which extracts the RPM and tries to immediately install it.
  • has almost a thousand lines of post-install and pre-uninstall scripts (!!).
  • uses those hundreds of lines of post-install scripts to unpack files, add files, and remove archive files during the installation.

(Newsflash to Sun: you should do all that before you build the RPM, and then package the final result as the RPM. That's what RPMs are for to start with, the fully installed and unpacked binary version of your software.)

The Flash RPM I found refused to activate itself without an X display to talk to. So much for using that in RPM form at all. (Fortunately Flash is just two files in /usr/lib/mozilla/plugins, which is easy enough to do in a script.)

Others of the RPMs that I had to look at today 'merely' feel free to do things like delete RPM-managed files belonging to other packages and replace them with symlinks.

Things like this matter because almost everyone running Fedora Core 4 is managing a great deal of their system through RPM. When a package mangles the system behind RPM's back, the entire environment becomes fragile. (All of the stuff I covered in CPANProblem applies.)

The irritating thing about these system manglings is that by and large they're unnecessary, especially things like the JDK ugliness. These companies are not running into novel problems in building RPM packages, and other software manages to do the right thing. The companies were just lazy. (And because of the license terms of their software, outsiders can't fix the problem, build proper packages, and distribute the results.)

(What'd I do? I shrugged, checked to make sure the post-install scripts didn't do anything too heinous, held my nose, and just used them as is. But I had to spend the time to read over the scripts, check out the results, and so on.)

Written on 27 August 2005.
« Two faces of RSS
Weekly spam summary on August 27th, 2005 »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Aug 27 03:33:59 2005
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.