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
.specfile when you’re packaging files into your
.rpm(both source and binary
.specfile contains meta-data about your package.
.specfile also contains the code to both build (for source
.rpmfiles only) and install your package.
.specfile 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
.specfile while you’re packaging an extension, there is no spec file in your
.rpmpackage. Instead, the information contain in the spec file because a baked in part of the binary
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
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.