Wednesday, February 18, 2004

RPMS

The first thing I found was how annoyed I was getting when during the debug/test cycle I would have to hand copy files around. That forced me to write a script to do the copying for me. From there, it was a quick jump to having a makefile and then RPMs.

As a packaging system, RPMs are pretty nifty. They are lightweight, and the creation process handles a lot of the gruntwork for you. Compared to HP/UX and Solaris, they are amazing! The only problem? The documentation. The documentation that is provided at rpm.org is incredibly out of date. So much so that the examples don't work anymore.

Once you get around that, it is very handy. The automatic dependency generation even found some bugs in my code!

I do wish it played better with CPAN. That it goes and finds all sorts of Perl dependencies is nice, that it isn't able to look at the already installed Perl modules (through CPAN) is a bit of a pain. I guess I'll have to figure out how to use cpan2rpm. :)

Tricks? Try to avoid having hardcoded versions in the spec file. For example, if you have:

Version: 0.4 Release: 1

in your spec file, you will have to edit it for each Version/Release that you do. Not a great way to spend your day. To get around it, you can specify things on the command line. First, you will need to add the following to the top of your specfile:

%if %{?rel:0}%{!?rel:1} %define rel 1 %endif %if %{?ver:0}%{!?ver:1} %define ver 1 %endif

How it really works, I'm not sure. Once I hit the problem with the code examples in the RPM docs not working, I stopped reading. :) However, it seems to define a variable if it isn't already defined. Once you have that, you can change your Version/Release entries to:

Version: %{ver} Release: %{rel}

Then, you invoke rpmbuild like this:

% rpmbuild --define "rel 2" --define "ver 1.0"

That sets those variables from the command line, a great time saver.

No comments: