Needs rebasing

Is there a practical way to do this with changes to the changelog?

IMO it makes sense to make these changes separately

Which changes, and how could they be separate? The update is a fairly major one, which requires the note in the changelog. It doesn't make sense to separate them.

I took your question to mean that you wanted a way to avoid conflicts. If you insist on keeping the changes in the same commit, there appears to be no way around resolving the conflict, i.e. rebase ...

Splitting this into two commits isn't going to change the fact that it's vulnerable to conflicts in the release notes. I'd be happy to rebase, but won't that create a new commit each time I do? If the extra commits are fine, I'll just do it.

The rebase creates a new changeset, so does not entail superflous commits (perhaps you're thinking of merging master into the PR branch?). You will need to force-push the branch after rebasing, however.

I generally disagree that you necessarily need to check in both the bump and the changelog to master at the same time. The changelog pertains to the next NixOS release; to my mind, preparing that changelog is a separate concern from ordinary package bumps.
People running NixOS from random checkouts must be expected to read the git log (which I think is the appropriate medium for incompatibility notices). In that sense, splitting things up does help, because it doesn't block updating a package due to conflicts in (what I consider) an unrelated piece of the repo (the NixOS changelog).

If you want to solve the underlying problem of incompatible edits, maybe propose per-package changelogs/warnings or something. Some mechanism for delivering important info pertaining to package updates to end-users apart from the git log would be great (ala eselect news), but that seems outside the scope of this PR.

Aah, okay, I understand what you're intending now. I'll make those changes to this PR shortly...

Sorry, I didn't test this thoroughly enough. I suggest reverting, unless a quick fix for #56621 can be done.

@laMudri if a short-term fix turns out to be impossible, please submit a revert PR & I'll be happy to merge it. I suppose it needs to be reverted from the upcoming release branch as well (I've not checked if it's in there)

Is it just executables (no loadable modules)? Then adding wrapGAppsHook should work.

@jtojnar It is just executables, but I tried adding wrapGAppsHook to nativeBuildInputs but it didn't solve the issue. Possibly gconf is involved too, though it's difficult to find the time to work it out right now.

Is the error still the same? I can see that adding wrapGAppsHook to nativeBuildInputs includes the GSettings schema path in the wrapper and that there are gschemas.compiled so everything looks fine.