On Mon, 22.06.09 01:55, Adam Sampson (email@example.com) wrote:
> I don't think it's a good idea to make the D-Bus interface the public
I am Linux developer. My priority is Linux.
rtkit is Linux-specific, internally it makes use of quite a few
Linux-only features. Which makes it very small and lean. I like it
> You appear to be heading this way with your example client code in rtkit
I guess one can't have one's cake and eat it too.
I don't think it is worth creating a tiny mini library that I'd need
to maintain and everyone depend on for just one (or two) little
function call. Especially since this would be an extra dep to a lot of
software. D-Bus otoh is nowadays so deeply integrated into th system
(heck, we now have it in the init system itself, too, and there
has been work to add kernel code for socket(AF_DBUS)), that it's
available everywhere and on many projects a dep anyway.
Also, the reference client should compile fine on non-Linux, however
it will become a NOP and return ENOSUPP when you call it. I added this
precisely to allow compilation of the code on other OSes and
minimizing the ifdef orgies.
> You also need to be careful about licensing. The license status of D-Bus
Uh? To me it looks as if dbus was AFL/GPL2+ which a verified with a quick
grep over dbus' git repo.
How did you come to the conclusion that dbus was AFL/GPL2-only? Can you
point me to where this is claimed?
> rtkit-test.c claims to be GPL v3 or later, which isn't possible,
dbus is GPL2+. When linked against the rkit daemon that gets
practically upgraded to GPL3. Problem solved.
> (Incidentally, why the "-Kit" naming? There seem to be a few packages
Hehe, it's all davidz's fault.
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
Linux-audio-dev mailing list