[MacPorts] #17950: dbus patched with launchd support and version dump

[MacPorts]

#17950: dbus patched with launchd support and version dump
---------------------------------+------------------------------------------
  Reporter:  jonas.baehr@…       |       Owner:  macports-tickets@…                   
      Type:  enhancement         |      Status:  reopened                             
  Priority:  Normal              |   Milestone:  Port Enhancements                    
 Component:  ports               |     Version:  1.7.0                                
Resolution:                      |    Keywords:  launchd kde4 x11                     
      Port:  dbus                |  
---------------------------------+------------------------------------------

Comment(by jonas.baehr@…):

 Replying to [comment:37 mta@…]:
 > Replying to [comment:36 jonas.baehr@…]:
 > > I think the solution is to ask launchd for the address if
 DBUS_SESSION_BUS_ADDRESS is not set, ''or it contains a launchd:
 address''. The latter is currently not the case. I'll fix that.
 >
 > It's not clear to me that it's that simple, although I don't understand
 this code well enough to be sure.  The "launchd:..." address comes from
 _dbus_server_new_for_socket which constructs it from the string
 "launchd:key=session" passed to it from
 _dbus_server_listen_platform_specific and a guid created and appended by
 _dbus_server_init_base.  Then this is passed, via the
 DBUS_SESSION_BUS_ADDRESS environment variable, to the child configd-2
 process.  It's not obvious that having that child process get the
 DBUS_LAUNCHD_SESSION_BUS_SOCKET from launchctl will return the correct
 socket name.  What's the guid good for?  Should it be used some way to
 look up the socket?  Should the server be doing this and assigning the
 correct Unix socket name to DBUS_SESSION_BUS_ADDRESS?  It's questions like
 this which kept me from implementing a fix.

 The code you mention is to spawn a server (a dbus-daemon instance), not to
 get the bus address from within the client. gconfd-2 is a dbus client
 though. Look at init_session_address in dbus-bus.c to find the behaviour I
 described. A platform-specific look-up is only performed is
 DBUS_SESSION_BUS_ADDRESS is not set.

 I'm not sure which is the best approach to fix it. In fact, launchd: is
 not a real address type, but rather an address lookup method. So, with
 this in mind it might be a solution to pass the real unix:path=/foo
 address to _dbus_server_new_for_socket (in dbus-server-launchd.c).
 However, something like this
 {{{
 DBUS_SESSION_BUS_ADDRESS="launchd:key=session" dbus-monitor
 }}}
 won't work with it... (That's exactly the problem gconfd-2 has, when
 autolaunched by dbus-daemon)
 The question is now if we want launchd to behave like a real address type,
 or if it's just a lookup/pseudo-adress only valid in a server config file.

 Since it does not make sense to lookup the same address again I'd say one
 should set the server's address to unix:path instead of reconstructing the
 original launchd address, which is then used again in the client to lookup
 the socket. This doesn't feel right and should fix our gconfd-2 problem
 (every autolaunched service, in fact). Accepting launchd: addresses in
 DBUS_SESSION_BUS_ADDRESS can be a second step.

-- 
Ticket URL: <http://trac.macports.org/ticket/17950#comment:39>
MacPorts <http://www.macports.org/>
Ports system for Mac OS