Hacking RPMs with rpmrebuild

A couple of months ago, I discovered a tool called rpmrebuild while searching for a way to reverse engineer the files installed on an older Fedora system back into its original RPM package. Rpmrebuild is able to reconstruct an RPM by looking up the information about it on the RPM database that is part of every RPM-based distribution like Fedora.

But rpmrebuild doesn’t stop there; you can also modify actual RPM packages without needing access to its SRPMS or even knowing much about SPEC files. Although this may not be recommended when dealing with core/base Linux system RPMS, it is incredibly useful for developers, release engineers, and system administrators who needs to create internal RPMs for their organizations.

For example, it is common practice for release engineers to have a “back out strategy” in case a release does not meet requirements during installation. With rpmrebuild, the version and release numbers of an RPM that may be replaced by a new one can be tweaked so that in case there is a failure and the ”back out” RPM is needed, the release engineers can simply install the back out RPMs over the new RPMs. Then the back out RPMs will have higher version and/or release numbers on them, so a tool like up2date or yum can automatically pick up on the changes.