Hello there.

I'm trying to package an application into an RPM in order to have it installed/updated automatically and unassisted in a large number of desktops.

As an end user, I'd always thought that rpms and dpkgs where the silver bullets of software management, and through yum and apt-get I've run hundreds of seamless updates of programs while they were at that point running; from firefox and openoffice to the xorg server or the linux kernel.

However, now that I've glimpsed the inner workings of RPM and am trying to write one myself I'm stuck on how to write it so the update doesn't break anything in case it's applied while the app is running.

As a concrete example:

Mine is a java app and let's say I update a couple of jars. If my running app then happens to load a class from a new jar that is not compatible with some already-loaded classes from the previous version, I'm screwed.

A similar problem would arise if I update the app's database schema while the thing is runnig.

So, my question is:

How do the programs I mentioned (and many others) manage to pull it off? I've looked at firefox's, tomcat's and openoffice's spec files without finding anything in particular. They seem to just overwrite their files and get on with it.

I'm particularly interested in the rpm way of getting things done, but any and all replies concerning the update of running apps are welcome with open arms.

I'd really appreciate any comments you could give me on this. Even if all you could do was to point me somewhere else where you think I'd have a better chance of getting some answers, it would be tremendously helpful. So far I've tried the RPM mailing list with little results.

I thank you already for taking the time to read this long post.

Regards.

Adrián.

You are, I hope, aware of the basic difference between *nix file systems and the MS type. That is, that when a file is accessed in a *nix system, the access is accomplished by moving into memory the entire set of pointers to the physical locations of the data on the HD. (There is little overhead to this since almost all files in *nix systems reside in contiguous blocks.) When a *nix file is deleted, the newly created "free" space is not made available for use until all processes which accessed the file have terminated. Thus a process (e.g., rpm) can "delete" a file that's in use and create a new version, but any process that's accessed the file prior to the deletion will continue to access the old file.

In the scenario you're describing, your app would need to be dynamically loading the jar which is, I suppose, possible. So your app should simply check the version number that you've cleverly embedded in your code to flag the problem, and, more to the point, access all the jars that can be used by the app as soon as the app is loaded (and verify the release numbers) so the memory pointers will be stored for the life of the app. Thus updating from an RPM should not effect any running app.

Welcome to LQ!

First , there's no silver bullet! Hey, that's what Brooks said.

Since you are researching on this you must have reached the RPM Guide for sure. If not, now is the time. It's an excellent resource for RPM.

You are correct. There's a responsibility from the package maintainers side. But package managers also have tricks of their own.

I'd stop here and leave you to the RPM Guide. It has the info you are looking for. The guide explains how to build RPMs and in the process it explains how to handle the cases you are talking about.

EDIT: PTrenholme has posted more info above. While the post is mostly from a developers perspective, mines from a package manager softwares perspective. Hope both provides helpful insight.

Thanks a lot guys! You both gave me great answers.

@PTrenholme: I did have a some idea about the *nix handling of files you mention, but I didn't consider it the way you did. I thought that 1) the app might not have accesed some of its files yet and 2) it may have opened a file and after being done with it (for the moment) relinquished references to it, then the next time it accessed the file it would get the new version. What you're pointing out here is a great suggestion, so I'll be looking into the details of *nix file management right away.

@SkyEye: Yes, the RPM guide is an excellent resource. I've read quite a bit of it but so far I haven't found any mention to this particular issue of updating running apps. There's a section named 'Planning for upgrades' but it just grazes on the subject.

I thank you again for your answers, they were very helpful.

I've been asking around a bit more and the updates I thought to be 'seamless' are not quite so: friends of mine have had applications like, for instance, Thunderbird having some or other functionality broken after an update to have it restored upon app restart. I also came across a spec file for ypbind that clearly restarted the service after an update, so I guess that unless either your app is aware of the update process or it only consists of files that are referenced at all times by the running process, you're @%#"! when it comes to updating it while it runs.

I'll still be looking into all of this, so if anyone cares to provide further comments (RPM related or not) they'll be highly welcomed.

Thank you all.

Adrián.