/cc @jtojnar

Transmission and dconf-editor look fine, I am not familiar with libreoffice packaging, though.

I pushed the dconf-editor and transmission as cb6065f and a9746ab. Cannot test the libreoffice one.

@jtojnar Thank you!

I am not familiar with libreoffice packaging, though.
Cannot test the libreoffice one.

/cc @viric @7c6f434c
Notes for libreoffice changes:

• gsettings_desktop_schemas is propagated by gtk3 after gtk3: make GTK depend on gsettings_desktop_schemas #31891
• wrapGAppsHook is needed instead of wrapProgram --prefix XDG_DATA_DIRS "$out/share:$GSETTINGS_SCHEMAS_PATH" for GTK3 with Wayland backend ignores options in settings.ini #31293 (comment)

  nixpkgs/pkgs/build-support/setup-hooks/wrap-gapps-hook.sh

  Lines 29 to 31 in 7374650

  	if [ -d "$prefix/share" ]; then
  	gappsWrapperArgs+=(--prefix XDG_DATA_DIRS : "$prefix/share")
  	fi

LibreOffice change makes enough sense that I am willing to take the claims about testing at the face value.

I was more worried about wrapGAppsHook introducing unnecessary things into the libreoffice closure.

Guys, I'm confused >_>

@jtojnar

I was more worried about wrapGAppsHook introducing unnecessary things into the libreoffice closure.

But you said before that programs using wrapProgram --prefix XDG_DATA_DIRS $GSETTINGS_SCHEMAS_PATH

are most likely broken outside of GNOME (usually missing icon theme) anyway and should be changed to wrapGAppsHook.

I use LibreOffice but not that often and extensively to notice if something will become "subtly broken"

This is how everything behaves after #31891 under wayland compositors (except Gnome of course):

• program with or without GSETTINGS_SCHEMAS_PATH and without wrapGAppsHook that launched via menu doesn't inherit settings, though it inherits settings when launched from terminal
• program with wrapGAppsHook inherits settings when launched both ways

@7c6f434c

It looks like there is now dconf in the
closure, but I am not even sure if something is subtly broken without
it.

Where? Dconf is not required, but gsettings_desktop_schemas is required for one particular case: Gtk3 programs working under wayland compositors (except Gnome which prepares proper environment). Though Gnome guys switched from old settings formats to dconf settings far ago, they just not broke things for X11 backend, but haven't added similar legacy stuff to Wayland backend, so things appear to be broken only under Wayland. If you're interested see #31293

But you said before that programs using wrapProgram --prefix XDG_DATA_DIRS $GSETTINGS_SCHEMAS_PATH

Yes, the wrapGAppsHook will add everything necessary – but it will also add, for example, everything in build inputs that contains a share directory, even the things that are not needed.

• program with or without GSETTINGS_SCHEMAS_PATH and without wrapGAppsHook that launched via menu doesn't inherit settings, though it inherits settings when launched from terminal

GSETTINGS_SCHEMAS_PATH does not really do anything. It is only a helper variable created by glib to be picked up by a wrapProgram invocation or wrapGAppsHook.

Where? Dconf is not required, but gsettings_desktop_schemas is required for one particular case.

dconf library is a propagated dependency of wrapGAppsHook. We would like to remove it in favour of an impure solution (#11239) but it will require some work.

@jtojnar

GSETTINGS_SCHEMAS_PATH ... to be picked up by a wrapProgram

Meant exactly that (wrapProgram --prefix XDG_DATA_DIRS $GSETTINGS_SCHEMAS_PATH).

dconf library is a propagated dependency of wrapGAppsHook. We would like to remove it in favour of an impure solution (#11239) but it will require some work.

Oops, indeed. Termite shell messed tests on my side. Its a gtk program wrapped with wrapGAppsHook and it propagates wrapper context to the childs. Dconf library is indeed needed as well as gsettings_desktop_schemas to make programs use dconf settings.

Yes, the wrapGAppsHook will add everything necessary – but it will also add, for example, everything in build inputs that contains a share directory, even the things that are not needed.

So did we go a right route or there is a better way without possibility to break anything? I don't know one except a module with setting like ...useDconf = true; which will just add dconf library's gio/modules to GIO_EXTRA_MODULES and gsettings-desktop-schemas to XDG_DATA_DIRS environment variables.

So did we go a right route or there is a better way without possibility to break anything?

Making sure the resulting derivation does not contain unnecessary dependencies and splitting them would work for some (gobjectIntrospection #32293). Other, unfortunately, contain share directory that is only needed during make (appstream-glib) – for those, in order not to be included in the derivation, we would need to teach wrapsGAppsHook to distinguish between build-time and run-time dependencies. That could be accomplished either by adding a new attribute for explicitly listed the dependencies to add to the wrapper, or by excluding those in nativeBuildInputs.

I don't know one except a module with setting like ...useDconf = true; which will just add dconf library's gio/modules to GIO_EXTRA_MODULES and gsettings-desktop-schemas to XDG_DATA_DIRS environment variables

The schemas might be useful even without dconf backend, for now I would keep them.
dconf.nix module would append to GIO_EXTRA_MODULES as you describe, see example