[feature] support for nonstandard typelibdir and girdir

[attila-lendvai]

i'm trying to package gpaste for Guix. Guix is like NixOS: they have a read-only store directory, and prefer to have direct links to every dependency (e.g. /gnu/store/x91g7aak23j75915067x73aald26afvy-gpaste-3.42.2/lib/girepository-1.0/).

everything works, except the gnome-shell-extension, due to: Requiring GPaste, version 1.0: Typelib file for namespace 'GPaste', version '1.0' not found.

in this setup the typelibdir and girdir compile-time variables must be set at, well, compile time, to point to the store directories.

you can see the diff below of how it's hacked in nixos (the diff first adds @varname@ tags that are then replaced when the package is built with the actual paths):

https://github.com/NixOS/nixpkgs/tree/master/pkgs/desktops/gnome/misc/gpaste

AFAIU, what would need to be done for this to work nicely is to delegate the variables that are in the makefile into the source code. but then: does such a hardcoding make sense on the FHS based distros? i don't know.

ideally, there should/could be a --with-typelibdir and a --with-girdir for the ./configure script, or some -Dfoo=bar for the meson config, but i don't know these tools/domain well enough to be able to open a PR for this.

to clarify: this is not a showstopper, i hacked my way through with the Guix package using the diff from NixOS, but it would be much nicer if this was supported by gpaste.

[attila-lendvai]

i'm pretty much clueless about gnome and glib stuff.

with that in mind: typelib was certainly an issue, but i think the second issue was not gir-dir, but the setting schema in share/glib-2.0/schemas and the gschemas.compiled file next to it.

for now it looks like i need to call 'glib-compile-schemas' by hand in the guix package (https://issues.guix.gnu.org/53072).

[attila-lendvai]

FTR, this has been fixed meanwhile in Guix, and it works.

(well, it used to for a while. right now gpaste dies with a sigsegv, but that's probably a different issue (gpaste-client --version dies with GPaste-CRITICAL **: 00:47:00.000: Error calling StartServiceByName for org.gnome.GPaste: Process org.gnome.GPaste received signal 11)).

@Keruspe please see the Guix patch here:

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/gpaste-fix-paths.patch

and if you don't find anything actionable in it, then feel free to close this issue.

[Keruspe]

Do you have e.g. one typelibdir per package, or just a global nonstandard one?

[Keruspe]

Never mind, the answer was already in your initial report. Do you have the same issue with e.g. the "official" gnome-shell-extensions? How do you handle this ?

[attila-lendvai]

[EDIT] it was a guix packaging bug, and it has been fixed.

FTR, this is the Guix sigsegv bug report:

https://issues.guix.gnu.org/58191

but most probably it's something Guix specific.

[attila-lendvai]

FTR, the Guix patch to GPaste has been updated since then:

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/gpaste-fix-paths.patch

(@gschemasCompiled@ and @typelibPath@ gets replaced by actual paths at package build time)

[jtojnar]

I do not think it makes much sense to upstream such specific patches. They are pretty ugly hacks that do not really make sense outside of NixOS and Guix.

The only benefit would be that we would not need to maintain the patches locally. But I am not convinced it is reasonable to push the burden on Keruspe. Especially when they probably would not have any way to test the code path so it would likely end up bit rotting.

[attila-lendvai]

@jtojnar i'm not proposing to upstream the actual patches that NixOS and Guix use currently. i assumed, possibly mistakenly, that there's a standard way to control these variables through ./configure and friends.

you do have a point, though, that upstream has no way to test this feature...

unless it's wired in unconditionally, and it defaults to the current default paths on the standard distros? and then the Nix and Guix build could use the same mechanism?

but now that i have struggled my way through this issue on the Guix side, i won't be disappointed if this issue is closed with a won't fix.

[jtojnar]

No there is not a standard way. Unfortunately, a lot of GNOME is designed with the assumption FHS (or similar global nexus) is available and the projects often use process-global registry with no way to unload modules once they are loaded.

In case of gobject-introspection, there is GIRepository, which allows only prepending lookup paths for the rest of the process lifetime. And GNOME Shell extensions run inside gnome-shell process.

It might be possible to not modify the lookup paths but I have not tested it and it becomes unwieldy once there are multiple typelibs:

Possible patch that reduces amount of global state changed for GIRepository

--- a/src/gnome-shell/extension.js
+++ b/src/gnome-shell/extension.js
@@ -6,9 +6,10 @@
 
 const Config = imports.misc.config;
 
+imports.gi.GIRepository.Repository.get_default().require_private('@typelibDir@', 'GPaste', '2');
+
 imports.gi.versions.Clutter = Config.LIBMUTTER_API_VERSION;
 imports.gi.versions.GLib = '2.0';
-imports.gi.versions.GPaste = '2';
 imports.gi.versions.Pango = '1.0';
 imports.gi.versions.St = '1.0';
 
--- a/src/gnome-shell/prefs.js
+++ b/src/gnome-shell/prefs.js
@@ -4,7 +4,8 @@
  * Copyright (c) 2010-2022, Marc-Antoine Perennou <[email protected]>
  */
 
-imports.gi.versions.GPasteGtk = '4';
+imports.gi.GIRepository.Repository.get_default().require_private('@typelibDir@', 'GPaste', '2'); // Not sure if this one is necessary.
+imports.gi.GIRepository.Repository.get_default().require_private('@typelibDir@', 'GPasteGtk', '4');
 
 const ExtensionUtils = imports.misc.extensionUtils;
 

GSettings schemas in similar situation but there we cannot even wing it with setting a lookup path – each GSettings object used by a library needs to be patched, which results in monstrosities like what we do for evolution-data-server (we have created a tool for generating the patches for C projects at least). The downside is that Gio.SchemaSource objects start proliferating, you cannot store the GSettings schemas in the standard location (or you get conflicts between gschemas.compiled files when using buildEnv/symlinkJoin), and global GSettings overrides will not work.

[attila-lendvai]

No there is not a standard way. Unfortunately, a lot of GNOME is designed with the assumption FHS (or similar global nexus) is available and the projects often use process-global registry with no way to unload modules once they are loaded.

then, i guess, this issue should be closed with a won't fix, right?

i'll leave the decision to others, though, who are more knowledgeable on this territory.