[Nix-dev] Fwd: Dealing with dbus

[Mathijs Kwik]

I think you have a valid point. I too have walked into similar
situations with other packages.
Restricting dbus calls sounds like a useful solution.
Personally I would like these kinds of meta-configuration accessible
in the package expression itself (special attribute sets) and then
have nixos treat them some special way.

On Fri, Sep 13, 2013 at 3:23 PM, Sergey Mironov <grrwlf at gmail.com> wrote:
> 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
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev