I hate RPM packaging.

One of my side duties at work is preparing a disk that (ab)uses our upgrade process to flash the bios on the raid controllers every time IBM releases yet another attempt to make it work right. In the past, what I’ve had to do is make a RPM that installs a couple of “.ufi” files that the %post part of the RPM then uses the arcconf program that’s already on the system to flash the ROMs with. That was fine and dandy, until IBM decided that instead of distributing a ufi file, they’d distribute an ELF binary that included within it the ufi file, the arcconf program, and some other cruft like a script to run it and instructions. Fine, I thought, rather than bothering to unravel all the crap, I’d just package the executable into the RPM and run it in the %post. And it didn’t work. After much sweating and swearing, I finally got it working.

Did you know that the rpmbuild process automatically does a “strip” on any ELF binaries it finds? I didn’t. Did you know that IBM’s packaging of a binary file inside an ELF binary doesn’t work if you strip the file? I didn’t. Did you know that the command to tell rpmbuild to NOT strip the file is almost completely undocumented and obscure to the point of pointlessness? I didn’t. Did you know that the best reference for building RPMs, “Maximum RPM” is no longer available on rpm.org, and the replacement doesn’t have an index or a search function? I didn’t.

Am I annoyed? You bet.

For the benefit of future searchers, here’s how you keep RPM from stripping your binaries. You put the following in your rpm spec file, preferably near the top:

# This stops RPM from stripping the .bin files, which breaks them.
%define __os_install_post \
/usr/lib/rpm/redhat/brp-compress \
/usr/lib/rpm/brp-python-bytecompile \
/usr/lib/rpm/redhat/brp-java-repack-jars \
%{nil}


Intuitive, eh?