I’m still no great shakes as a Ruby coder, but I’m continually amazed at how much can be accomplished with a very few lines of code.

As an example, I mentioned that I’ve been buiding a lot of Solaris packages and Linux binary RPMS lately. One thing I miss on Linux is an equivalent to Solaris’ pkgproto command, which is used like this:

find /path/to/binaries | pkgproto > prototype , or also

pkgproto path ... > prototype

This is how Solaris handles the equivalent of the %files section of a RPM spec file. One thing to like about pkgproto is that it captures owner, group and permissions of each file. Linux supports an
%attr(owner,group,perms) name-of_file

construct; however, Linux provides no tool to directly generate this. In a very few lines of Ruby, I was able to implement a pkgproto equivalent that produces output with each line looking like this:

file_type %attr(uid,gid,perms) filename

This can then be read into the RPM %files section (after stripping the first field). I prefer to use a separate file, combined with the %files -f in the RPM spec file. I’ll discuss how I use that first field in a subsequent installment.

I love that Ruby; a tool to build tools.

-k-

Technorati Tags: redhat, RPM, ruby, Solaris

Well, my sed woes are over, and I’m not going crazy, at least because of that. As I detailed yesterday, I had a seemingly incorrect script, that apparently though unaccountably, did the right thing.

After further review, I discovered the application being packaged rewrites the file upon startup and shutdown. Apparently, the inputs to this rewrite process are obtained from files that were successfully created and converted during the Solaris pkgadd. Bottom line is, I need not have fiddled with the offending file at all. This is a hazard of 3rd party applications, when one knows little of their internal workings. The instinct, mine at least, is to convert every file that has a hostname, IP address, etc., that is different from the system on which you are currently installing the package.

I wish that vendors would supply a more transparent interface to their install/configuration process, without surrounding it with their (usually GUI) interface. I know the suits like GUIs, but they are rarely responsible for installing stuff on bunches of machines at once. And don’t even mention the “silent install” options some vendors offer. By using those, one loses the ability of the Solaris pkginfo command, or the Linux rpm -qa command to determine at one fell swoop what exactly is installed on a system. My mantra is if native OS tools are good enough to install the OS, they’re also good enough to install any applications the system needs.

Sometimes being old school is rough, but in this case worth it.

-k-

I’ve been converting some third-party software to Solaris packages(so you can use pkgadd) and Linux RPMS over the last few days. It’s the typical drill; install with the vendor’s install software, bundle up the resulting files, and surround with judiciously-crafted scripts to perform configuration. Then test, test, test.

As part of a postinstall script on Solaris, I have some innocent sed commands that resemble this:

sed -e “s/some_string/${some_environment_variable}/” \
-e “s/another_string/${another_env_variable}/” some_file > some_other_file


And I thought all was well until today. I’d installed the new package on a couple of Solaris systems, and everything worked. I then used those scripts as templates for my Linux %post section for the RPM. I then observed that one of the files operated on by the sed script had multiple instances of some_string on a single line of the input file. The above instructions to sed, in absence of a the “g” modifier, should have replaced only the first instance of some_string. But on Solaris, all instances were replaced, pretty as you please. I even hacked out the sed script, ran it from a shell, and only the first instance was replaced. So it appears the postinstall script handles something differently; it’s called from pkgadd. I am at a loss to explain what’s going on.

Things that work, when they apparently shouldn’t, are as troublesome as things that don’t work, when they apparently should.

-k-

Interventions of vacation, life, and “other priorities as assigned”, temporarily de-railed my Ruby efforts. I’ve been getting back on track for the last couple of days, and the hiatus was actually beneficial. I figured out some new ways to structure my program to greatly enhance its maintainability and more importantly its extensibility. Add to that that I now must support three Linux releases on three different kernel architectures, plus several Solaris releases, and the time away turned out to be a good thing.

I’m excited to get this thing done, but I’m also painfully aware that this will be the worst Ruby I’ll ever write, since it’s my first effort.

-k-

Even though this isn’t a Rails project, I thought the geekily inclined would appreciate the “derailed” and “back on track” references in the above.

Technorati Tags: ruby