Change:
<ins> # Seahorse. { config, pkgs, lib, ... }: with lib; { # Added 2019-08-27 imports = [ (mkRenamedOptionModule [ "services" "gnome3" "seahorse" "enable" ] [ "programs" "seahorse" "enable" ]) ]; ###### interface options = { programs.seahorse = { enable = mkEnableOption "Seahorse, a GNOME application for managing encryption keys and passwords in the GNOME Keyring"; }; }; ###### implementation config = mkIf config.programs.seahorse.enable { environment.systemPackages = [ pkgs.gnome3.seahorse ]; services.dbus.packages = [ pkgs.gnome3.seahorse ]; }; } </ins>

Discussion:
Describe the bug Currently, the gnome3 module automatically adds the following to I know that is still experimental, and probably shouldn't be installed by default. Does GNOME3 document their distribution defaults anywhere? I think we could clean this up slightly. Note that if we remove anything from here it would be a good idea to conditionally add them based off the users . That way current users won't see these packages magically disappear from their machine. Or perhaps it's better document that in the release notes.
cc
If I recall correctly, we should be concerned about core and world:
Ahh, looks like there's a bit to do here. For example should be :wave:
I think it is just CI breakage after they removed , see
So after discussing briefly in irc, I guess we can implement profiles for gnome-world-packages gnome-games-packages And the module will continue to bring in , , and . In the future we can split that up so we can use flashback without gnome3. Then we can eliminate the lists in since that should be in the profiles where it's useful. One thing I'm unclear on is how to organize the profiles, and do they have options to enable?
Thinking about it more, the main benefit of profiles is that they would not need options. But if we want parts of the profiles to be disableable, we would need to have options for them anyway. Also with options, we get generated documentation for free. I am not sure that is a way to go an more. As for the subdivision, maybe it would make more sense to look on it from users’ perspective: Hard-core hacker wants a bare-bones GNOME Shell with minimum necessary services, not even file manager or terminal emulator – they already have favourite ones. Casual user might have some favourite apps but they are generally happy to use whatever comes with the desktop environment. Here we would ship the core apps. An organization such as a library might want a full desktop environment for their shared workstations, with programs for all possible purposes. But they probably have a sysadmin who wants to have a fine control over what gets installed on the workstations. For that reason, creating a profile that bundles all the world apps probably does not make sense.

Non-GNOME users who want to use GNOME apps probably do not want to use all GNOME apps either, so a core collection might not make sense for them. A parent wants to install various games on the children’s computer. This is kind of similar to the organization but here the collection is more useful. …
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there: