[Nix-dev] Fwd: Dealing with dbus

[Sergey Mironov]

not replyed to all by mistake

---------- Forwarded message ----------
From: Sergey Mironov <grrwlf at gmail.com>
Date: 2013/9/13
Subject: Re: [Nix-dev] Dealing with dbus
To: Mathijs Kwik <mathijs at bluescreen303.nl>


Thanks for the clarifications. Yes, it is nixos who currently handles
systemd units and it surely can deal with dbus services so I would
probably have no problems packaging some dbus service. But there is a
thing bothering me - it is the inability to specify reverse
dependencies from nixpkgs to nixos.

Lets look at the situation from the client side: for example,
xfce4-power-manager wants to call upower in order to suspend the
system. Had it used the command line-tool like pm-suspend, we would
just write  { .. pm-utils .. } in the xfce4-power-manager.nix as
usual. But we can't do similar thing for upower due to it's dbus
nature. Or, to be more precise, we can, but we can't restrict
power-manager from calling anything else so it would not actually help
us to maintain the package. Heh I even didn't know it needs upower
until I looked into sources.

Naturally, Nixpkgs handles link-level dependencies very well by
allowing only some specific libs to link with. Also, it handles
path-level deps by restricting PATH calls. Network-level deps is out
of it's scope and the question is - may we extend the usual logic to
this case and restrict DBus calls somehow? IMHO we need something to
error loudly when a program calls a dbus interface which is not
enabled for it in its *nix file.

Regards,
Sergey

2013/9/10 Mathijs Kwik <mathijs at bluescreen303.nl>:
> Sergey Mironov <ierton at gmail.com> writes:
>
> This kind of thing touches the boundaries between nixpkgs and nixos.
>
> First of all, I think your usecase should be handled by systemd.
> Systemd knows about dbus, knows which services exist and their dbus
> names. It is capable of handling requirements/ordering of these.
>
> But currently, a nixos module has to be written for every nixpkg that
> provides a service, which means stuff ends up somewhat separated. If a
> binary within a package moves from /bin to /sbin, any nixos module that
> uses it needs to be fixed. Getting nixos and nixpkgs a little out of
> sync will break things.
>
> For other os-level functionality though, packages can provide things
> like udev rules and kernel modules themselves. You tell nixos to use
> these, but leave the implementation to the package.
>
> I think something similar can/should be done for systemd units.
> Some packages already include a unit file, but for others I think a
> passthru attribute "systemd-units" would be nicer. Then you would only
> need to tell nixos to use these, or do this automatically for
> environment.systemPackages. Of course these would still be
> overridable/tweakable if people need slightly different configs.
> (that's why I think passthru is better than including a plain unitfile)
>
> Similar things can probably be done for things like firewall rules.
> If daemon-containing packages would carry info about which ports to
> open, just saying something like
> networking.firewall.daemons = [ pkgs.mysql ];
> would be very nice.
>
> Of course this is all a bit offtopic to your question, but you reminded
> me about the somewhat unclear nixpkgs/nixos distinction by pointing out
> you want to put os-level settings/deps inside a package description,
> which I think is a natural thing to do.
>
> For now: just use nixos' systemd.services attributes to tell systemd
> about dbus names and dependencies of your services.
>
>
>
> Mathijs
>
>> 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
>> something like
>>
>>
>> { stdenv, fetchurl, pkgconfig, ... dbus ... dbus_server1, dbus_derver2 }:
>>
>> stdenv.mkDerivation rec {
>>   name = "udisks-1.0.4";
>>   ..
>>   buildInputs =  [ dbus ];
>>
>>   // Means that udisks should have it's DBUS_PATH containing at least
>> dbus_server1 and dbus_server2
>>   dbusPath = [ dbus_server1 dbus_server2 ];
>> }
>>
>> Does dbus provide an opportunity to organize thing like that?
>>
>>
>> Regards,
>> Sergey.
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev