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.

Using XML for export/import of DB install values In many systems, you find a bunch of sql code that gets executed at install time. This code is usually brittle, hard to read, and generally nasty. My last employer had a lot of code like this, and it was just that, VERY nasty. I've just come up with, I hope, a better way. I'm using XML to store the data, and then reading it and using my existing database (see: Class::DBI) classes to handle the insertions/updates. This gives me the following benefits:

1. I'm using the same code to do the initial insertion that I use in the regular running of the system, so I only have to fix a bug once
2. When I migrate to different new database, I don't have to port the installation code
3. My code handles changes, as well as additions. So, if you change the value of a column, the loader will handle that properly, instead of doing simple "inserts" - see find_or_create() on Class::DBI
4. The XML file is generated from my test database (see: DBI::Generator::XML) so I don't have to edit it by hand
5. I can generate test data programatically and load that at any time
6. I can dump test data from the system without hardcoded primary key id values!
7. If I have to edit the file by hand, I can

All sorts of benefits. :) The ability to keep on executing the script without it deleting and re-inserting all of the rows is of special benefit. It lets me progressively add more information to the rows (such as comments) which aren't needed right away. Now, without the export, there is no real benefit. Hand editing XML isn't really pleasant. Hand modifying the XML is handy, you don't have to do too much typing. :)

First Post! Wow, my first post. Never having used a blog before, this will be interesting. Essentially, I'm doing this because I find that I'm writing my friends a lot of emails on the subjects, and I don't really want them to be lost. :) As an introduction and scope, I'm writing a Project Information System. If you're interested, you can find out more information at Pollock.ca I've got an early release of the Requirements Management System up there. I will be talking about Perl, XML and software development.