randy at linuxfromscratch.org
Thu Apr 21 09:44:48 PDT 2005
Jürg Billeter wrote these words on 04/21/05 11:27 CST:
> 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)
Good tip. Thanks.
>>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
Yeah, I kinda figured that, but not having used D-Bus and HAL enough
to be comfortable, I thought I'd just throw this out. Thanks for the
>>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
> required dependency.
Thanks for the cluebat about Pyrex. I never even thought about it
being a package I should have installed.
>>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."
Again, thanks for the cluebat.
>>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.
This is good to know. /tmp is the default, however, I wasn't sure
if *user* owned sockets should be in /tmp. Thanks for the tip.
>>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
> BLFS maintainers.
I read about the ABI breakage. I read that HAL is caught up, and
I was/am not sure where other packages stand.
Thanks for the very good information, Jürg. I'll defer to Bruce's
decision whether to add D-Bus and HAL to BLFS now, or wait until
after BLFS-6.1 is released.
Someone mentioned in (I believe this) mailing list that HAL is now
required by one of the GNOME-2.10 packages. I don't remember which
one. I installed DBUS and HAL, as they are optional depends of
GNOME-VFS, so I thought I'd just get them out of the way, and watch
carefully any package's interaction with HAL.
I have not installed enough of GNOME-2.10 to see which package it
was/is that requires HAL.
Again, thanks for all the information.
rmlscsi: [GNU ld version 220.127.116.11.2 20041220] [gcc (GCC) 3.4.3]
[GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686]
11:33:00 up 19 days, 11:06, 3 users, load average: 0.08, 0.04, 0.01
More information about the blfs-dev