Sergey Mironov 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
