This blog entry is from Greg Riedesel (http://sysadmin1138.net)
David Nally taught RPM Packaging for Systems this morning at LISA '12. There were a few absentees, but as David pointed out, it was early on a Sunday so some of that is to be expected. That didn't stop him though.
He opened up with a slide-deck to give background on why package management is a good thing, and why we as sysadmins need to be doing more of it. Not just RPM, but package-management of anything, be it .debs, Microsoft MSI's, or ruby Gems.
The big question? Why should sysadmins care about this?
-
Repeatability – packaging is a form of automation after all, and automation is what we do.
-
Change Management – packaging greatly eases several change management tasks by being fully automated, and discouraging local configure/make/install style software management.
-
Audit – Using a platform's package-management tools allows us to easily discover what software is installed.
-
Verification – RPMs at least allow you to check installed files with what should be installed.
-
Documentation – A spec file is a form of documentation after all, it tells you how to build a specific software package.
-
Renown – Getting involved with packaging for a FLOSS project is something sysadmins can really do to contribute without having to write formal programs.
Packaging is a skill we all need.
David then dived into the details of RPM itself, specifically, spec-files. He went over each of the headers and sections in a spec file, and brought up commented examples for the class to walk through. He touched on some platform differences; SLES is a bit different than RHEL for instance, but pointed out where to look for the changes.
There is a variety of tools to assist with RPM handling outside of the core utils like rpmbuild, and David covered some of them. Items like gem2prm, which takes Ruby gems and turns them into an RPM, and cpan2rpm, which does the same kind of thing for Perl.
Then the class got let loose on some Virtual Machines that David set up before the class. The VM had a RPM build environment, and a selection of spec files, and we were told to build stuff and fix problems. Some worked right away, and others needed some work, like installing build requirements. One gave us quite a bit of grief - the version simply wouldn't build. Fixing it required downloading a newer version from upstream and updating the spec file to reflect this.
All in all, it was a good class. Hands on at the end, which helped hammer home the points he was making about how these files work.