Utilizing macros can make life easier when you’re dealing with building on, and for, multiple platforms. Why bother with hard-coding full paths to system utilities when you can simply refer to them by their macro name? These can also be useful for avoiding things like rpm check-files errors, installed (but unpackaged) file(s) found, and debuginfo related stuff.

If you’ve ever run into a dreaded configure problem such as C compiler cannot create executables, and gotten lost in a tangle of glibc/cc/g++ packages, you might find that building source rpms using Mock turns a multi-step process into a breezy single step. Build source rpms using mock which builds inside a chroot. This lets you compile 32-bit on 64-bit without a problem. Check out mock configurations in etc. You may have preconfigured configurations for your Linux distribution.

Start the spec file with %define statements at the top. Continue the spec file as you would normally, using the variables you just defined in place of the real name, version, build. Create an rpmbuild script that replaces the template variables with current information. Make an rpm target in your Makefile that calls the rpmbuild script.

Defining things like %_topdir and %_smp_mflags for all your rpmbuilds can be done in the hidden rpmmacros file in your build user’s home directory. The problem is portability. If you define unnecessary things such as %_tmppath, and try to use it in your spec files, everything will work fine until the day you or someone else attempts to build without having their rpmmacros set up quite the same way.

With rpmbuild, you can make custom packages for any architecture, but what if there’s no difference between the architectures in what you’re building. If you’re copying around something like scripts, docs or other text files that have nothing to do with 32 vs 64 bit or endianness, it’s easier and more efficient to create a single noarch package and just keep one copy of it in a repository.

Rpmbuild’s RPATH feature is used to search libraries outside of standard paths. They are given to the linker at buildtime. If the developers of the code you’re trying to turn into an RPM did not take any of these considerations into account when they write their programs then you may be forced to skip check-rpath.

Wow, there are a crap load of dependencies to build qpid, the AMQP client/server libraries for C++! What do you mean my architecture isn’t supported? Bah, whatever… Add ppc to the list or rip it out for now. Just build it and stop complaining!

I’ve found 3 ways to disable the strip binary option when building RPMs.