Nixpkgs: virt-manager needs dconf as runtime dependencie to store settings

[wucke13]

Issue description

As the title states, virtmanager needs dconf. Otherwise, a lot of quirks appear, as virtmanager heavily relies on dconf to store settings (like default connection to libvirt, vmviewer specific things like autoresize and so on).

Steps to reproduce

• run an window manager / desktop environment which does not provide dconf
• start virtmanager
• add a default connection
• restart virtmanager, see how the connection disappeared

Technical details

• system: "x86_64-linux"
• host os: Linux 4.14.90, NixOS, 18.09.1799.b9fa31cea0e (Jellyfish)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.1.3
• channels(root): "nixos-18.09.1799.b9fa31cea0e"
• channels(wucke13): "nixpkgs-unstable-19.03pre161900.61c3169a0e1, nixos-unstable-small-19.03pre161392.50bb0afa7ce, nixos-unstable-18.09pre150708.083220867c7"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

[jtojnar]

Duplicate of https://github.com/NixOS/nixpkgs/issues/42433

See https://github.com/NixOS/nixpkgs/issues/42433#issuecomment-419614845

[wucke13]

I'm still not convinced. In some way, dconf for sure is a service. But, virtmanager is a program, not a service. And it does not fully work when it is missing the dconf-service executable (which besides acting as a service also is a plain executable). So, if one program (read executable) depends on another executable to fully work, whats wrong with just providing it (the other) as a runtime dependency?

[jtojnar]

The dconf-service executable is not on PATH, though. It is launched by the D-Bus daemon.

You can see it clearly in the following system configuration:

  environment.systemPackages = with pkgs; [
    (gnome3.dconf.overrideAttrs (super: {
      postInstall = ''
        rm -r $out/share/dbus-1
      '';
    }))
  ];

The service will not start with this snippet. On the other hand, if you remove the postInstall section, it will start correctly. I am not really sure why the service is even registered in this case; the proper way to register a D-Bus service is though services.dbus.packages option.

Nix currently simply does not have any mechanism that would allow modifying the global system state when a package is installed. Actually, that would be a huge violation of purity.

As a side note, there is propagatedUserEnvPkgs hack that adds the listed dependencies to the profile the package is installed to, but that would only work when the package was added to the system profile (through environment.systemPackages), relying on the accidental service registration described above. In all other cases, the global service would still need to be registered manually.

[wucke13]

That indeed is more convincing. Thanks for taking the time to clarify this!

[jtojnar]

I would really like if we could specify

{
  passthru.globals.requiredDbusInterfaces = [ "ca.desrt.dconf" ];
}

and dconf package would have

{
  passthru.globals.providedDbusInterfaces = [ "ca.desrt.dconf" ];
}

and then nixos-rebuild would warn the user when the global requirements are not met.

[wucke13]

Please explain this:

$ nixos-option programs.dconf.enable
Value:
true

Default:
false

$virt-manager
[...]
(virt-manager:28463): dconf-WARNING **: 02:35:33.888: failed to commit changes to dconf: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name ca.desrt.dconf was not provided by any .service files

Your suggestion of using programs.dconf.enable = true does not work, adding dconf to the system environment does. I'm confused.

[jtojnar]

Do you have https://github.com/NixOS/nixpkgs/commit/88ae8f7d55efa457c95187011eb410d097108445? It is quite recent and might not have been backported.

[wucke13]

I guess you're right. Thanks again!