GNOME Bugzilla – Bug 138457
bonobo-activation-daemon needs to be killed on upgrade
Last modified: 2006-08-14 16:49:44 UTC
From an upgrade report I made to debian-gtk-gnome: Upon restarting gdm manually, I got into a situation that the panel refused to start ("The panel's already running, so I won't start!", and apparently gnome-settings-daemon was respawning uncontrollably. This was apparently because bonobo-activation-daemon needed to be killed. Also unacceptable; it should be killed on startup if it is an "old" version, and destroyed on shutdown also.
Moving to libbonobo. It should go away when you log out really. What version are you using?
I was using 2.4.3, and upgraded to 2.6.0 (along with much of GNOME 2.6) and experienced the problems mentioned.
Yes - unfortunately, this is 'just one of those things' - inasmuch that we have no way to hand-over the connection state from one to the other, so - some weirdness will always occur here. As Kjartan says though - it should quit when you log-out really; if not some mis-behaving application is still using it when it should not (often evolution-alarm-daemon).
Should we keep this open as a RFE to handle upgrading b-a-s?
IMHO killing b-a-s on upgrade is a distribution issue; we should close this.
right - this is a non-bug IMHO, and luckily b-a-s almost never changes so it's hardly likely to cause issues.
Maybe these days it's "hardly likely to cause issues," but I'd just like to mention that it definitely *did* cause me issues in the past.
I won't argue that, it's beside the point. My point is, what is the point of adding a "killall bonobo-activation-server" to an install-local rule in the makefile? People use distributions, with package post-install hooks, not makefiles. Fixing it upstream doesn't make any difference in the real life.
Actually, I never intended for it to be a makefile rule. I wanted GNOME to "know" that b-a-s needed to be killed, then do it. (I guess, ideally, there would never be backwards-incompatible changes, but...)