I’ve been digging into the internals of linux package management systems the past few days (side note: if you’re successfully delivering a piece of packaged unix software to the entire linux community without the help of the distro maintainers: my hat’s off to you) and it took me a surprising amount of time to unearth what, exactly, an RPM package’s .spec files do , and where they live .
It was one of those cases where there were five pieces of information, and most articles/tutorials explained three of them really well while assuming you already knew the other two.
You create a .spec file when you’re packaging files into your .rpm (both source and binary .rpm files). The .spec file contains meta-data about your package . Your .spec file also contains the code to both build (for source .rpm files only) and install your package. Your .spec file also contains what I would lifecycle scripts but RPM calls Scriptlets and Triggers , which allow you to run code at certain points during a package’s install and uninstall routines. Finally, while you create a .spec file while you’re packaging an extension, there is no spec file in your .rpm package . Instead, the information contain in the spec file because a baked in part of the binary .rpm file itself.It’s this last part that threw me for the biggest loop. When I extracted the files from a package I didn’t see a .spec file, so I started thinking .spec files were a “package time only” thing, but other things I read made it clear that wasn’t the case, and wtf is going on they don’t just bake this information into the file do they that would be cra― oh, that’s what they do.
This means you can’t really get a package’s .spec file ― you need to extract the .spec information you want . In my case that was the installer script and a little help from the rpm command line program (the rpm tools are available on Mac OS via homebrew )
rpm -qp --scripts name-of-rpm.x86_64.rpmI’ll probably have more to say on linux package management in the future, but for now here’s hoping this helps anyone else digging through the foundations of linux systems.