[Nix-dev] Dealing with dbus

[Vladimír Čunát]

On 09/09/2013 11:07 AM, Sergey Mironov wrote:
> Hi. Let me suggest discussing the DBus and the guidelines for
> packaging software which uses this technology. I suppose that plain
> including dbus into the dependencies list of a package like that:
>
> { stdenv, fetchurl, pkgconfig, ... dbus ...  }:
>
> stdenv.mkDerivation rec {
>    name = "udisks-1.0.4";
>    ..
>    buildInputs =  [ dbus ];
> }
>
> is not the best thing to do because we are offering little guaranties
> to the user this way. We are actually saying that the package needs a
> network, but in reality this package needs the network AND one or more
> specific servers in order to work correctly. Could we do something
> better? For example, could we treat DBus as just another way of
> launching programs, develop the concept of DBUS_PATH and write
> [...]

I just stumbled upon the fact that dbus services (living in 
share/dbus-1/services/) are supposed to be found according to [XDG 
spec], so it should be enough to set those variables via a standard 
wrapper to add more particular services to be visible for a given 
executable. Cf. [dbus docs].

I'm not sure if we e.g. include the system and user profile dirs, so 
just installing services in there made them available, etc. It's quite a 
question whether to make as many implicitly shared services available to 
executables as possible, or to limit it to fixed versions via wrappers.

(My current context: tumbler https://github.com/NixOS/nixpkgs/pull/1206 )

[XDG spec] http://freedesktop.org/wiki/Standards/basedir-spec
[dbus docs] http://dbus.freedesktop.org/doc/dbus-daemon.1.html


Vlada


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3251 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20131116/dcb2c0ff/attachment.bin