Better dconf support, and removal from packages

[lucabrunox]

Currently we have some bad experience with dconf:

• Packages hardcode the gio module. This is good because it keeps abi compatibility with the linked glib, however it's also true that gio modules API hasn't seen any change since its first release in version 2.30.
• NixOS modules add dconf to the system packages, making it impractical for the user to disable it.

Proposal:

• Remove dconf references from every package.
• Add services.dconf.enable, which adds the system package and the GIO_MODULE env var.

This way we cleanup packages, make it possible for services to services.dconf.enable = mkDefault true; and let the user disable it with services.dconf.enable = false;.

cc @vcunat

[domenkozar]

What about non-NixOS?

[lucabrunox]

@domenkozar same as nixos? If the user wants dconf, the user will install it. If any other distro doesn't have dconf, also its applications won't save settings in dconf. I don't see any problem with nix packages in that regard.

EDIT: perhaps the only problem could be GIO_MODULE, but do you really want to add this variable to every glib package? I'm not sure.

[ghost]

as I commented in #11108 , I think we could split dconf into service and gio module.
and only wrap apps with the gio module. this keep the ABI compatibility using about 70K (libdconfsettings.so).

[lucabrunox]

About ABI compatibility there's no harm, it's been stable since 2.30. Yet non-nixos users may have troubles as you say.

For icons we have a default, and people can simply override it globally.
For GIO_MODULE however the story is different. Why only dconf and not also glib-networking hardcoded in programs?

About multiple-output, agreed we can do this.

[ghost]

well, webkitgtk based browsers have hardcoded glib-networking for a long time,
I think other applications are not network-related, so they don't need it.

[zimbatm]

could we have the dconf package set the GSETTINGS_BACKEND on install like cacert does for SSL_CERT_FILE ? then it can be installed either as a user or in the system.

[davidak]

This is still an issue with many GTK applications. A general fix would be great instead of fixing every single one separately.

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.