This post appeared originally in our sysadvent series and has been moved here following the discontinuation of the sysadvent microsite

I tend to dislike scattering my file-systems with non-packaged script modules, be it Python, Perl, or Ruby. So I wrap rpm packages for my systems. But packing is such a bother, you might say. That might be true, but luckily, we have good tools to help us.

gem2rpm, semi-automatic spec-file generator

To build this website, we used Jekyll, an excellent small ruby HTTP server for static content. Jekyll is available as a standard Ruby gem, but not as rpms for Fedora. In the following, I show how I built and installed Jekyll via rpms only, on my Fedora system, using gem2rpm - a semi-automatic rpm spec-file generator for Ruby gems.

To build rpms from Ruby gems, we need the rubygems and rubygem-gem2rpm packages. For RHEL and clones, we may find gem2rpm in the EPEL repositories.

sudo yum install rubygems rubygems-devel rubygem-gem2rpm

Set up the rpmbuild-tree

If we do not have it already, we install the rpmdevtools package collection, and set up the rpmbuild-tree

sudo yum install rpmdevtools

Fetch, generate, build

Note that in the following, we assume that there are no matching gems in ~/rpmbuild/SOURCES , so we can use simple name*.gem wildcards.

First fetch the gem source for Jekyll.

cd ~/rpmbuild/SOURCES
gem fetch jekyll

Generate the rpm spec-file. If we want, we might inspect the file before continuing. For more advanced usage, we could use ruby templates to control the result more. But for now, the defaults are good enough.

gem2rpm jekyll*.gem > ~/rpmbuild/SPECS/jekyll.spec

Build the rpm package

rpmbuild -bb ~/rpmbuild/SPECS/jekyll.spec


Script apps tend to require a lot of libraries or modules, so we need to check for missing dependencies. The following small script queries the packages just built for their rubygem requirements, then asks if they exist in the repositories, and shows those that are missing.

rpm -q --requires -p ~/rpmbuild/RPMS/noarch/rubygem-jekyll*.noarch.rpm |\
  awk '/^rubygem\(/ {print $1}' | sort | uniq | while read p; do \
  yum whatprovides "$p" > /dev/null 2>&1 || echo $p;


So we need to build these packages as well. I incidentally know that I also need jekyll-paginate for this project, so we add that to the list.

Rinse and repeat

We build these the packages the same way. First download the gem with gem fetch. Then generate a spec-file with gem2rpm, before finally building the package with rpmbuild. So let us build a loop that do them all in one go:

for g in \
  colorator \
  mercenary rouge \
  jekyll-sass-converter \
  jekyll-watch \
do gem fetch "$g"
  gem2rpm "$g"*.gem > ~/rpmbuild/SPECS/rubygem-$g.spec;
  rpmbuild -bb ~/rpmbuild/SPECS/rubygem-$g.spec

This might take a few moments, so we drink a cup of our favourite advent hot brew while waiting. If all went well, we might finally install the packages. In this case, they are all architecture independent, so they are all found in ~/rpmbuild/RPMS/noarch

cd ~/rpmbuild/RPMS/noarch
sudo yum install \
  rubygem-mercenary-*.rpm \
  rubygem-colorator-*.rpm \
  rubygem-rouge*.rpm \

Using this, I can test this sysadvent blog locally.

More than ruby gems

So far, so good with ruby gems. What about other scripting languages? Are there similar tools? Can we do similar tricks with them? Of course we can. For Perl CPAN modules, have a look at cpanspec. PHP pear has even built-in support for generating rpms from pear modules. Check out pear make-rpm-spec. Python packages can be wrapped as rpms using pyp2rpm. If everything else fails, we might go dirty, and use fpm. Or we might even build an rpm package from scratch, it is not that hard.

Easter egg in an advent blog

That is all. There are bonus point to anyone who found the LoTR reference.

Ingvar Hagelund

Team Lead, Application Management for Media at Redpill Linpro

Ingvar has been a system administrator at Redpill Linpro for more than 20 years. He is also a long time contributor to the Fedora and EPEL projects.

Containerized Development Environment

Do you spend days or weeks setting up your development environment just the way you like it when you get a new computer? Is your home directory a mess of dotfiles and metadata that you’re reluctant to clean up just in case they do something useful? Do you avoid trying new versions of software because of the effort to roll back software and settings if the new version doesn’t work?

Take control over your local development environment with containerization and Dev-Env-as-Code!

... [continue reading]


Published on February 27, 2024

Portable Java shell scripts with Java 21

Published on February 21, 2024