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

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.
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
If we do not have it already, we install the rpmdevtools
package
collection, and set up the rpmbuild-tree
sudo yum install rpmdevtools
rpmdev-setuptree
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;
done
rubygem(colorator)
rubygem(jekyll-sass-converter)
rubygem(jekyll-watch)
rubygem(mercenary)
rubygem(rouge)
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.
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 \
jekyll-paginate;
do gem fetch "$g"
gem2rpm "$g"*.gem > ~/rpmbuild/SPECS/rubygem-$g.spec;
rpmbuild -bb ~/rpmbuild/SPECS/rubygem-$g.spec
done
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 \
rubygem-jekyll-*.rpm
Using this, I can test this sysadvent blog locally.
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.
That is all. There are bonus point to anyone who found the LoTR reference.
Open source i offentlig sektor - utmaningar, möjligheter och vägen framåt.
Denna artikel beskriver processen och lärdomarna från att släppa ett API som öppen källkod inom offentlig sektor. Projektet, som utvecklades för digitala nationella prov (“DNP”), visar hur öppen källkod kan stärka samarbete, transparens och innovation. Artikeln lyfter fram både möjligheter och utmaningar – från säkerhet och juridiska aspekter till kulturellt motstånd – och ger insikter för andra myndigheter som överväger liknande initiativ.
Slutsatsen är att öppen källkod ... [continue reading]