GNOME Bugzilla – Bug 129540
module config file should not hardcode platform dependent paths
Last modified: 2018-02-10 04:33:50 UTC
According to FHS, files in /etc should not include platform dependent data, if it is possible. In case of gtk+-2.x it is problem of hardcoded ModulesPath in gtk-query-immodules-2.0 and gdk-pixbuf-query-loaders. Fix: Do not prepend hardcoded modules path and shared library suffix to config file, but to library. See more in bug 129534 for potential consequences. See /etc/gnome-vfs-2.0/modules/*.conf for (mostly) correct solution.
The gnome-vfs solution (as far as I can tell, just putting the filename without any path)is, IMO, not really workable, since it doesn't handle having different sets of modules for different architectures. It also doesn't handle pango.module files (in home directory, uninstalled) that want to point to files outside of the installed location. The specific problem that you can run onto on the current Fedora/Red Hat x86-64 setup (I think SuSE is similar, but am not sure) is that you can have two pango packages installed at once, with files /usr/lib/libpango-1.0.so.x.y.z /usr/lib/pango/modules/* /usr/lib64/libpango-1.0.so.x.y.z /usr/lib64/pango/modules* You need two separate pango.modules files, one for x86-64 and one for i386. The existence of a pango-querymodules binary in both packages is a problem, since the library packages for different architectures shouldn't share any files. What I did in the current Fedora packaging for Pango is /usr/bin/pango-querymodules-32 /etc/pango/i386-redhat-linux-gnu/pango.modules /usr/bin/pango-querymodules-64 /etc/pango/x86_64-redhat-linux-gnu/pango.modules However, with this scheme updating pango.modules when installing a module is a real pain - you have to know the name of pango-querymodules for the module you are installing and the location of the file to update. What I'm thinking of doing is copying how fontconfig handles the fonts.conf cache files. In rough outline, Pango has a path of standard locations to look for modules; for the x86_64 libraries, that would be something like: ~/.pango/modules/1.4.0/x86_64-redhat-linux/ ~/.pango/modules/1.4.0/ ~/.pango/modules/ /usr/lib64/pango/1.4.0/modules Pango looks in all of these directories when started up for a pango.modules file with cache information for that directory. If not found, it looks for ~/.pango.modules-x86_64-redhat-linux in the users home direcrory for cache information. If that's not found it goes ahead and queries the modules in that directory and writes out the missing cache either in the system direcoory (when writable) or in the home directory file. Pango installs a pango-querymodules binary that basically just does the same thing as Pango would do when started up for use in post-install scripts. On multi-arch platforms, pango-querymodules would be a shell script that does essentially: for arch in 32 64 ; do test -x /usr/bin/pango-querymodules-$arch && /usr/bin/pango-querymodules-$arch done The reason that you need the pango-querymodules script is to handle cases with shared home directories over NFS; the user may be logging into different machines with different sets of modules, and in that case, bad things will happen with module data in the user's home-directory.
*** Bug 126328 has been marked as a duplicate of this bug. ***
Not going to get to this for 2.4.0.
*** Bug 139987 has been marked as a duplicate of this bug. ***
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
In the FC3 gtk2 rpm, I have fixed this by moving the config files to /etc/gtk-2.0/i686-redhat-linux/gtk.immodules /etc/gtk-2.0/i686-redhat-linux/gdk-pixbuf.loaders renaming the binaries to gtk-query-immodules-2.0-32 gdk-pixbuf-query-loaders-32 and add shell scripts update-gtk-immodules update-gdk-pixbuf-loaders which expect to be called like update-gtk-immodules i686-redhat-linux and figure out which binary to call and which config file to update.
Related bug 153848.
*** Bug 156786 has been marked as a duplicate of this bug. ***
Looking at glibc sources, it has a code, that interprets $LIB, $PLATFORM, and $ORIGIN in library paths. Maybe we can copy it (or create it as a glib function). Related: bug 153848
One part of this bug was worked around by moving of the cache to libdir in GTK+3. Maybe localstatedir with platform specific path would be better, but libdir is acceptable as well. The second part - gtk-query-immodules remains. The solution proposed in the comment 6 seems to be acceptable (maybe the wrapper can integrate both GTk+2 and GTK+3.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.