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 <[email protected]> wrote: > not replyed to all by mistake > > ---------- Forwarded message ---------- > From: Sergey Mironov <[email protected]> > Date: 2013/9/13 > Subject: Re: [Nix-dev] Dealing with dbus > To: Mathijs Kwik <[email protected]> > > > 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 <[email protected]>: >> Sergey Mironov <[email protected]> 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 >>> [email protected] >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> _______________________________________________ >> nix-dev mailing list >> [email protected] >> http://lists.science.uu.nl/mailman/listinfo/nix-dev > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
