Bug#406453: 32bit libgtk2.0 must use /etc/gtk-2.0/gdk-pixbuf.loaders.32

Loïc Minier lool+alioth at via.ecp.fr
Wed Jan 17 22:50:52 CET 2007


On Wed, Jan 17, 2007, Goswin von Brederlow wrote:
> To get ia32-libs-gtk working properly chunks 1+2 of the patch need to
> be applied. Chunks 3+4 just round things up by allowing the admin and
> user to have different gtkrc files if they so choose.

 I've started looking into the problem last week, and it's relatively
 complex.  Actually, for module pathes, Gtk will try plenty of pathes
 (as you might have seen in straces), so either we support a diversion
 of all of these (such as /etc/gtk-2.0/$host => /etc/gtk-2.0/$host.32),
 or we simply advice people to move away of these pathes (by default, a
 path including the triplet is checked).

 I've given some thought on how to handle this, and I don't want to spam
 all users with a fat NEWS.Debian, so I thought simply supporting
 diversions for what Debian ever shipped is enough
 (in /etc/gtk: gdk.loaders and gtk.immodules), and we shouldn't bother
 with supporting anything else at the code level, but this should be
 documented in README.Debian.
   I think this is particularly true for ~/.gtk-2.0 modules as I can
 imagine users compiling an IM method if they need one.
   I doubt changing the lookups in /usr/lib is useful, however I did not
 have time to look at all getenv calls to see whether or not some
 modules can be forcibly loaded without a full path via env vars.

 I'm not sure about handling of gtkrc, what made you customize this one?
 The possibility of loading modules from gtkrc?

> +# if defined (__i386__)
> +      result = g_build_filename (GTK_SYSCONFDIR, "gtk-2.0", "32", "gdk-pixbuf.loaders", NULL);
> +# else
> +      if (! g_access(result, R_OK))

 I've collected patches from all other distros last week, and while they
 all use different names, I would prefer we use one of the existing
 names.

 Ubuntu:
    GTK_SYSCONFDIR, "gtk-2.0", "gdk-pixbuf.loaders.32",
 OpenSuse:
    GTK_SYSCONFDIR, "gtk-2.0", "gdk-pixbuf64.loaders"
 Fedora:
    GTK_SYSCONFDIR, "gtk-2.0", HOST, "gdk-pixbuf.loaders"
    (-DHOST=\"$(host_triplet)\")

 (BTW, Fedora uses a slightly nicer test:)
    g_file_test (result, G_FILE_TEST_EXISTS)

 The patches are attached.  My personal preference goes for the Ubuntu
 option, but the Fedora one might be the best as it re-uses a path which
 is already handled by Gtk, the only difference is that the path is
 preferred when present and no further path is used; this might be
 problematic with the default location of the loaders which we
 currently use, and it's too late to change it for this cycle.

-- 
Loïc Minier <lool at dooz.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ubuntu-0815_ia32-hack.patch
Type: text/x-diff
Size: 3223 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20070117/702b3edc/ubuntu-0815_ia32-hack-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opensuse-gtk64.patch
Type: text/x-diff
Size: 6881 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20070117/702b3edc/opensuse-gtk64-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fedora-gtk+-2.4.1-lib64.patch
Type: text/x-diff
Size: 1757 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20070117/702b3edc/fedora-gtk-2.4.1-lib64-0001.bin


More information about the Pkg-gnome-maintainers mailing list