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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
