Linuxworld 2005, 10:15 AM - 11:30 AM, RPM Package Management.

[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.

Comments

• Anonymous
  August 09, 2005
  Imagine a blog entry where I talk about the midday keynote at Linuxworld 2005.
• Anonymous
  August 09, 2005
  The comment has been removed
• Anonymous
  August 10, 2005
  You might be interested in these too ..
  
  This page has bunch of state transition diagrams which show how the debian pkg management system handles various tasks. Its interesting to note quite how many different states a package can have.
  
  http://women.alioth.debian.org/wiki/index.php/English/MaintainerScripts
  
  Another difference I seem to have come across while mainating rpm based systems is that packages seem to depend on files not other pacakges. The latter seems to me the way to go since a filename could be used by another package, or there could be an epoch in the api. The pacakge management can express these if a pacakge can depend on a package it can quote versions etc. (The debain mechanism include conflicts: as well as depends: entries).
• Anonymous
  August 10, 2005
  "InstallShield = Windows" is even wrong in both directions. We all know that there are many tools that can create setups for Windows (Windows Installer as well as proprietary technologies). But on the other hand, InstallShield can also create non-Windows setups, including RPM packages and setups for Mac OS. (And now that they are merging with ZeroG/InstallAnywhere I guess they are the market leader on the cross-platform market)
• Anonymous
  August 10, 2005
  Wow, if InstallShield is the only option we have for Windows Installer, we are all in a lot of trouble.
  
  I might be biased, but it's sad really that InstallShield and Windows Installations are synonymous with each other. ...considering IMHO it is one of the worst installer products on the market.
• Anonymous
  August 11, 2005
  Stefan, I didn't mean to imply that Josh meant that InstallShield was only for Windows only that for Windows there was really only InstallShield. Which of course we all know is wrong because I talk about WiX here all the time. <smile/>
  
  But I won't fault the guy for only recognizing the market leader in installation builders, especially if his focus is on Linux.
• Anonymous
  August 11, 2005
  sandman, you are right and I oversimplified my comment in the sake of taking notes quickly. What I actually saw was that dependencies are between any two entities in the RPM package. For example, Josh showed an example where there was a name like "webclient" and another package depended on that. No files necessary.
  
  Interesting that "conflicts" and "dependency" sounds a lot like the ModuleDependency and ModuleExclusion stuff... just not at file level (which is something I believe is correct as well... but that's a blog entry for a different day).
• Anonymous
  August 12, 2005
  The comment has been removed
• Anonymous
  August 12, 2005
  fancyman, the MSI SDK was never intended to be the end user's entry point into interacting with MSI files. It may have ended up that way, but 3rd party vendors were really the target for the part of the MSI SDK related to creating MSI packages. Sorry you had to go through all the pain you did.
  
  1. Also, Microsoft has shipped (for a very long time) an MSI builder in Visual Studio. I personally think it is very underpowered and builds poor MSI files but it is there. I guess it was designed for those with simple setup needs and the expectation was that VS would just get you started then other companies (like InstallShield, Wise, and ZeroG, back in the day) would pick up from there.
  
  2. I'm glad you find the WiX toolset useful. None of the other tools around scale to the sort of setups that I see being built so it only made sense. It just took a lot longer to get released externally. <smile/>
• Anonymous
  August 12, 2005
  Thanks for your comments, Rob. Hm, I didn't think that Windows Installer SDK was intended for 3rd parties only. Just because Windows Installer is recommended way of distibuting applications and I thought it to be more easy to use(I don't mean technology itself, I mean tools). And without 3rd party solutions. So it was great to release such a tool and even opensource it.
  And it wasn't too much pain learning this SDK, after all =). Since without good knowledge of technology itself using WiX (or any other MSI authoring software) is impossible. Yes, I know about VS MSI builder, but I think it is not what to be integrated in such a powerful product =).
  
  About MSDE, MSMs... I didn't integrate MSDE an my setup projects, but I had to install MSDE SP4...
  
  "
  If the product code associated with your instance of MSDE 2000 is not listed, then the instance was installed by the setup utility of an application. You cannot use SQL2KdeskSP4.exe to apply SP4 to such MSDE instances. Instead, you must get a patch file from the company that wrote the application. If the application came from a company other than Microsoft, you must contact that company for a patch file. If the application came from Microsoft, refer to Microsoft Products that Include MSDE 2000, which lists the MSDE applications from Microsoft (this page will be updated with information about how to upgrade these instances of MSDE 2000).
  ". (Taken from SP4 readme)
  
  Yes, I also don't think that merge modules should work this way, because waiting for 3rd parties to distribute MS update is NOT the way it should be. Well, I understand that updates to a product can be applied only if update has the same ProductCode, that is OK. But when it is with MSDE, it is not OK... =)
  
  And the last thing. You told you've worked with Office team. As an IT, I MUST thank you and others who worked with office setup for your hard job. Since installing/updating/repairing/customizing office setup is really a neat thing. I guess, WiX was born while working with Office team...