Discussed some interesting ideas about dockapps with Mr. Zaphod Beeblebroccoli (a.k.a. mrbrocoli). Like the fantabulous dockable terminal. The dockable mail reader. And the dockable X server. Wow. Also, RPM support for APT is coming out nicely.
I've been thinking about stopping and restarting services on upgrade, and I'm not sure if it should be done with RPM as it is. Let's see why:
- RPM was designed to run unattended, and a configuration file will be either kept in place or updated with a new version.
- If the stock config file was not changed, it can be replaced by the new stock config file.
- If someone changed it, you can't replace it for the new stock version because you would exclude any customizations and eventually break the system or compromise security.
- Also you can't keep the old version, because the file format may have changed and it can break the service.
From (3) and (4), it seems logical that in case of configuration file changes, the service can't be restarted until someone checks what happened. Locally, because this service can be, for instance, sshd. But if some services are restarted, we'll fall in a non-deterministic situation: you'd never know what services stopped and what services have been restarted -- it's better to not restarting them at all!
So, it will always require human attention, which conflicts with (1). It doesn't work.
Even if you install a bunch of RPM packages by hand (i.e. not using apt), you'll need to dig up .rpmsave and .rpmnew files in the filesystem, change them and restart services. It can't run unattended :\ The only difference to what Debian does is that this last configuration update process can be quickly and safely addressed in Debian using debconf. With the extra bonus that you can set it to run non-interactively and it will send an email telling what has been broken in the non-interactive update.
Conclusion: just starting stopping services doesn't work. The unattended installation paradigm doesn't work, except if you keep it "unattended" only during the download and installation rounds (note that in Debian apt downloads all packages, then install the packages stopping services if necessary and in the last round it configures the packages restarting them when everything is ok). But in this case, we can add deferred configuration capabilities to RPM without breaking any paradigm, and the "philosophical argument" for not changing it is automatically declared bogus. Otherwise, RPM breaks its own paradigm by requiring human attention after installation, so adding deferred configuration wouldn't break anything.
I may be wrong, of course (If someone knows where, please enlighten me). I wonder how Mandrake's urpmi addresses this problem :\