On Tue, 2005-07-05 at 07:54 +0200, Martin Pitt wrote: > I see the point here. However, in Debian and Ubuntu we usually design > our packages in a way that they do not require a reboot in any case > but a kernel upgrade. Of course this is much more important on servers > to minimize downtime, but it has become a common standard, Policy, and > people expect it. Probably the way to think of this, as Havoc says, is that D-BUS is basically a userspace implementation of something that could/should be in the kernel. Here's a previous thread: http://mail.gnome.org/archives/networkmanager-list/2005-March/msg00022.html > Restarting hal/dbus on package upgrade has worked very well so far, > too. Our fine grained dependency system ensures that the matching > libraries are available, and with the reconnection patch we can get an > uninterrupted g-v-m session in all cases but HAL API changes (which > does not occurr very often, so that's not a big deal). Which do you think your desktop users will be happier with? 1) Sometimes, perhaps rarely, after upgrades or security updates, some things on the desktop mysteriously stop working or crash. They have no idea what caused it or what they need to do to fix it. They might eventually notice that rebooting seems to fix it. 2) Their OS works reliably all of the time, but occasionally notifies them that in order to gain new functionality from certain installed software they should reboot at some point. > Since I see that different distributions want to handle that > differently, what about making this optional with a ./configure-time > option? The problem is that: 1) These patches will complicate code significantly if they actually will work 2) Bug reports for this will also end up in the upstream Bugzilla, as Jeff and Robert mentioned 3) Distributors should have a unified handling of this so that application writers know what to do
Attachment:
signature.asc
Description: This is a digitally signed message part