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.rpm
I’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.