It is a responsibility of your desktop environment to enable GConf database, if you want to support legacy programs. Adding a module for each legacy program is too clutter-some, I would suggest introducing programs.legacy.gconf.enable instead.

Bumping the mono version is fine with me, though the requirement is weird – pdfmod is dead package after all.

@jtojnar I wouldn't quite put it like that. How should my desktop environment know that this one specific gtk program needs gconf? Especially for the newbie user, they'd just see that installing a specific package resulted in a runtime error every time they wanted open a file with it. And introducing a "hidden" feature like programs.legacy.gconf.enable wouldn't really help there either.

pdfmod being a dead package is certainly a valid point, however. In the interest of keeping nixpkgs relatively clean of such packages, maybe we should instead just completely remove it?

Can I suggest that we neither create a dummy NixOS module, nor drop the package from nixpkgs?

At the moment, the package produces a runtime error when GConf is missing. That's not ideal but probably better than the two choices above.

Re mono version, maybe let's just drop the override and go with the 'default' mono version since it's probably supported?

The fewer overrides, the fewer versions of mono users need to download (and we need to maintain).

mono 5.8 is the current default and that one still contains the magic number error on non-xterm terminals as mentioned above. Only mono versions >= 5.10, of which we package 5.14 as the latest stable release, contain that fix. I've changed the PR accordingly and excluded the dummy module again.

Could you please merge with #52712 ?