[continued from previous blog entry]

Okay, I found a free wireless base station. It is down at the end of one corridor on floor two but doesn't reach most of the conference rooms. The connection also seems slightly flaky (but that could just be my internal wireless, it's been acting up on me lately). I'll just post all my blog entries tonight.

While wandering after the opening Linuxworld keynote around I found a book that said what was been presenting where. One session at 10:15 immediately caught my eye, "RPM Package Management I." My understanding of RPM is less than rudimentary so I thought I'd drop in for a bit more than an hour and see how much I could pick up from the almost 3 hour class.

The presenter, Joshua Jensen (if I caught his name correctly) from Cisco, started by asking everyone if they've experienced the problem where you install one package on Windows and that causes another program on Windows to stop working. Those of us in setup know the problem as our age old nemesis "DLL Hell". A number of people were nodding.

Mr. Jensen used that story to launch into a discussion about what RPM is. For those of you who know less about RPM than me, RPM is an installation technology used by several Linux distributions and originally developed by Redhat (RPM stands for Redhat Package Manager). Mr. Jensen also implied that the dependencies in RPM solve the "DLL Hell" (or I suppose on UNIX it would be "so Hell") problem. Personally, I think that he oversimplified the problem and that dependencies, while a big part of the solution, are not the complete solution ("DLL Hell" is not a trivial problem). In any case, I do wish that the Windows Installer natively provided support for tracking dependencies. That has been an ask of mine since the beginning (you'll note that Merge Modules have dependencies).

Anyway, Mr. Jensen then went on to talk about a few other Linux distributions that use different technologies. Gentoo uses portage. Debian, and thus Xandros, uses apt-get (.deb files) for its installation technology. The he said, "And I guess Windows has InstallShield." That was an interesting comment. It made me wonder how many people think that the Windows Installer is really just InstallShield. I'll have to think about this topic more.

Anyway, after the color commentary was done (it seems common for each presentation to begin by bashing something about Microsoft), we got into some technical details about RPM. Here are the things I wrote down as Mr. Jensen spoke.

• During an upgrade, RPM first installs the new package and then uninstalls the old package. That's different from what I would expect. I wondered why this decision was made but Mr. Jensen offered no further insight. He did note that you have to think very carefully about your uninstall actions with this model.
• RPM overwrites configuration files unless the configuration files have been modified. If a configuration file was modified then a backed up is created (the with an .rpmsave extension) before the new configuration is installed. This behavior makes sense to me. The Windows Installer does part of this (it doesn't replace files that are modified). However, in RPM configuration files must be marked specially ("noreplace").
• In any case, configuration file changes must be made by hand after upgrade (although I expect there is post-processing that can be done by scripts inside a package). All of this behavior is kinda' what I expected but it was nice to see someone knowledgeable present the data.
• RPM actions should not be executed in parallel. In his demonstrations it wasn't exactly clear if RPM prevent multiple transactions from occurring at the same time but it seemed like it might. Again, this behavior makes perfect sense. In fact, the Windows Installer enforces the exact same restriction by preventing multiple installations from executing the InstallExecuteSequence at the same time.
• RPM supports queries for many useful pieces of data. The functionality reminded me very much of what data is available in the Windows Installer. The difference is that rpm is a command line tool and probably more discoverable and certainly easier to use than a bunch of APIs.

Overall, the presentation jived with what I little I understood about RPM and added a lot more depth. Based off my last bullet point, I'm seriously considering creating a simple little command line tool that displays the same sort of installation information (minus dependencies,) that RPM provides for Windows Installer packages. With my current understanding the technologies really appear to be more similar than different. Obviously, RPM has dependencies natively and the Windows Installer does not but the rest seems similar. Anyway, maybe it'll be something I'll start next year (I can't believe I have coding projects planned that are going to take me through the end of 2005).

Oh, by the way, I still didn't find any geeks. In this presentation, I got closer to programmer-types but this audience really felt more like IT-types than real code geeks. Again, I felt far more at home at OSCON than here.