j at bitron.ch
Thu Apr 21 09:27:59 PDT 2005
On Don, 2005-04-21 at 10:59 -0500, Randy McMurchy wrote:
> 2. The daemon is designed to be started via init as a 'system daemon',
> then started by users as a 'session daemon'. I do not have a good
> handle on this 'session daemon' stuff, yet.
eval `dbus-launch --sh-syntax --exit-with-session`
in /etc/X11/xinit/xinitrc.d/dbus should do it. More details on this and
other options in dbus-launch(1)
> 3. I do not have a good handle on the system configuration file
> used by the 'system daemon'. The default configuration file is
> enough to start the daemon, however, I've not used D-Bus facilities
> yet to know if it works as it's supposed to.
E.g. HAL seems to work fine without additional manual configuration.
Packages add extra configuration elements to the /etc/dbus-1/system.d
> 4. The bindings for Python and Qt cannot be installed (as best I
> could tell) because the configuration cannot find parts of Python
> and Qt. This is not a show-stopper.
Never tried Qt but Python seems to work fine, notice that Pyrex is a
> 5. I moved the path for the system daemon socket to /var/lib/dbus,
> but I don't know if we can use 750 permissions on this directory
> as I would think users need access to this socket.
Why? FHS explicitly states in the /var/run section
"System programs that maintain transient UNIX-domain sockets must place
them in this directory."
> 6. The default directory for session sockets (created by the
> individual user 'session-daemon') is /tmp. I tried to move this to
> ~/.dbus, but cannot pass the correct parameter to configure so that
> make will use an escaped ~. Even though I pass \\~/.dbus to configure
> and configure reports that the session socket dir will use \~/.dbus,
> make chokes because it says the ~ is not escaped.
Why should the socket be moved to the homedir? As it's machine dependent
(i.e. accessing the same nfs home dir from multiple machines probably
shouldn't reveal dbus sockets) and shouldn't persist between
reboots, /tmp seems fine, IMO.
> 2. Should we introduce D-Bus to BLFS now, or wait until we have a
> better handle on these issues. It very well could be that others are
> very comfortable and knowledgeable about D-Bus, however, I am not.
I'm using D-BUS since last summer, mainly for HAL but other system and
session bus users seem to work fine, too. I'd vote for adding it but a
few weeks ago the D-BUS (and HAL) api got broken, i.e. most released
versions of programs using D-BUS need to be patched to work with the new
api. Patches are relatively easy to find but it may mean more work for
Jürg Billeter <j at bitron.ch>
More information about the blfs-dev