Re: DBus on "other" platforms

On Thursday May 12 2016 13:47:25 Simon McVittie wrote:

>As far as I'm aware, Apple don't install dbus by default, provide it in

Indeed, so

>very easy to obtain and depend on. So D-Bus is clearly less "common" on
>OS X than on GNU and *BSD, and that's the OS vendor's choice, not ours.

Yes, indeed. But less common doesn't mean "fish out of the water" in my book.

>the well-known session bus, then D-Bus might still be useful for
>communication between cooperating applications (such as the KDE suite)
>on platforms where it is "uncommon".

Clearly that's the case.
>https://lists.freedesktop.org/archives/dbus/2013-October/015825.html
>summarizes our approach to how cross-platform or otherwise we are.

Thanks. Not the most recent resource ;) but still useful.

>Please encourage the maintainers of that port, and anyone else
>maintaining D-Bus "downstream", to talk to us about getting their
>changes integrated, or at least reviewed.

OK, will do.


On Thursday May 12 2016 14:10:49 Simon McVittie wrote:

>If MacPorts' dbus integration wants to run dbus-daemon without a pid
>file, they can use --nopidfile (available since 1.6.0, which is no
>longer security-supported so I hope they aren't running that or anything
>older).

No, the port is currently at 1.10.8 .
I presume that pid files aren't necessary for daemons/agents that are started through launchctl.


>If OS X can do credentials-passing across AF_UNIX sockets, then the
>correct long-term solution is to get that implemented compatibly in
>libdbus and GDBus, and then MacPorts can stop patching libdbus to be

So we'd be looking at patching GLib and libdbus?

>has at least getpeereid(), so it should be possible to support it in
>g_socket_get_credentials(). Since it has FreeBSD ancestry (I think?) it

FreeBSD or OpenBSD, I always forget which, but yes.

>might well also be able to support G_CREDENTIALS_TYPE_FREEBSD_CMSGCRED
>(search GLib source code for __FreeBSD__, it might just be a matter of
>adding __darwin__ or something to the __FreeBSD__ #ifdefs). However,
>again, this needs to be driven by someone who runs Darwin/OS X, or it
>won't happen.

Someone who runs OS X and has the required knowledge. It isn't very difficult to run OS X under VirtualBox nowadays, which might increase the potential population ;)

>I think I've run across this before: if I remember correctly, MacPorts
>splits up patches by the file they affect, not the logical change they
>make. If true, that's an unfortunate design decision.

I don't think that's an official design principle, but patches are indeed commonly named after the file they change.
>
>Setting that variable makes libdbus ignore the platform's poll()
>implementation, and emulate it inefficiently using select() instead.
>Does Darwin/OS X in fact have a broken poll() implementation, or is this
>a workaround for something?

I have no idea, the manpage just states that poll() doesn't support devices. It could well be that it's a remnant of an old patch from a previous OS that was never discarded because it still applies.

R.
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus