GNOME and the dbus daemon

It is a fact that dbus is becoming popular and that many parts of GNOME are starting to use it. Nowadays, some applications even fail to start if dbus is not present (e.g. epiphany).

Unfortunately, things do not work out of the box when installing GNOME from sources — or when using an "uncustomized" OS; see below — because there is nothing in GNOME that launches a dbus-daemon session at startup. Therefore, the user is forced to either:

• Change his ~/.xinitrc to do exec dbus-launch gnome-session instead of the traditional exec gnome-session.
• Edit his gdm configuration files to launch dbus-daemon before gnome-session.

As you can see, both "solutions" are cumbersome because they break the previous behavior and because they require the user to take extra steps to get things working.

Of course, in the disordered Linux world, distributions such as Ubuntu or Fedora Core include customized and rather complex X startup scripts that launch dbus-daemon during a session setup. Non-dbus-enabled systems (such as NetBSD) could ship modified gdm packages to avoid this problem, but users could still hit a problem when using the traditional startx or other session managers such as xdm or kdm.

I do not need to mention that some systems (e.g. NetBSD again) will not ever include — unless things change dramatically — a call to dbus-daemon in their standard X11 scripts.

A possible solution is to modify the gnome-session utility to spawn a dbus-daemon process on its own, just as it does with gconf or gnome-keyring. This way the user needn't remember to start dbus on his own as the GNOME session manager will do it automatically. With this in place, GNOME magically works again in these dbus-agnostic systems.

And yes, this solution is already implemented. It has kept me busy for two days but you can find the code in bug 336327. I hope to get some positive feedback and integrate it into pkgsrc until an official gnome-session release does it (if ever). If it is not integrated... well, I guess I'll have to go the gdm-patching route.

By the way, I have to say this: more than 300 lines of C code to do something that can be achieved in less than 10 lines of shell script... people seem to like to make their lives more complex than need be ;-)