Sergey Mironov <ier...@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@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev