For etch->lenny, if you really care, you could have an out of band (i.e. out-of-dpkg) preupgrade process which deletes the old dbus' package prerm script.
Now long term, there are multiple cases, as I argued here: http://mail.gnome.org/archives/networkmanager-list/2005-March/msg00033.html To sum that up, for security updates on servers, two things to keep in mind. First, probably the vast majority of servers today, DBus isn't even on the radar because it doesn't expose a network-accessible threat surface. Second, I bet a ksplice-style approach (http://web.mit.edu/ksplice/) would not be that hard to apply to DBus. We aren't generally changing the internal data structures much anymore. For the desktop use case, remember that most packages aren't being restarted. In particular, the X server and everything that depends on it is not being restarted. Solving *that* is fairly hard and requires vendor and upstream desktop integration work which I hope can occur in the context of PackageKit. In fact in general, installing a package is not the same as upgrading. Think about libc6. Its horrible postinst question is a symptom of this same issue. Is this bug release critical? I don't think so. On the server you can just not restart the system bus and no one will care. On the desktop for major version upgrades, no one is going to care if they have to reboot once, because you already had to to get those new X server drivers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
