After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 129540 - module config file should not hardcode platform dependent paths
module config file should not hardcode platform dependent paths
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other Linux
: Normal normal
: Medium fix
Assigned To: gtk-bugs
gtk-bugs
: 126328 139987 156786 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-12-17 13:00 UTC by Stanislav Brabec
Modified: 2018-02-10 04:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stanislav Brabec 2003-12-17 13:00:41 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.
Comment 1 Owen Taylor 2004-02-02 17:37:56 UTC
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.
Comment 2 Owen Taylor 2004-02-24 22:49:20 UTC
*** Bug 126328 has been marked as a duplicate of this bug. ***
Comment 3 Owen Taylor 2004-02-24 22:49:46 UTC
Not going to get to this for 2.4.0.
Comment 4 Owen Taylor 2004-04-16 19:17:20 UTC
*** Bug 139987 has been marked as a duplicate of this bug. ***
Comment 5 Elijah Newren 2004-06-19 18:42:45 UTC
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.
Comment 6 Matthias Clasen 2004-06-26 05:34:16 UTC
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.
Comment 7 Stanislav Brabec 2004-09-27 15:05:32 UTC
Related bug 153848.
Comment 8 Owen Taylor 2004-10-29 16:17:17 UTC
*** Bug 156786 has been marked as a duplicate of this bug. ***
Comment 9 Stanislav Brabec 2006-04-06 13:18:52 UTC
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
Comment 10 Stanislav Brabec 2012-01-19 18:41:41 UTC
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.
Comment 11 Matthias Clasen 2018-02-10 04:33:50 UTC
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.