Gtk 2.10 availability
Gtk 2.10.1-1 was uploaded yesterday to experimental (and 2.10.3-1 after
dinstall). This new upstream release is not compatible with
modules built with prior Gtk versions. Some longstanding issues have
been addressed in this release as well.
Here's a quick summary of the important news with emphasis on the
changes required or not in the installer.
The DirectFB backend is bundled upstream. With 2.10.1, no backports of
the DirectFB is required anymore and with 2.10.3, we're not patching
anything DirectFB specific anymore.
(This is not supposed to require any change in the installer.)
New module ABI
The module ABI has been bumped from 2.4.0. to 2.10.0. This means that
while Gtk 2.8.x has backwards compatibility with modules built with Gtk
2.4.0 or higher, modules need to be rebuilt against Gtk 2.10 and will
only work with Gtk 2.10.0 or higher. The API only changed for modules
of type "filesystem" which is currently only used to implement GnomeVFS
support in the file picker / file chooser dialogs.
I don't think the installer uses any Gtk modules for udebs apart from
modules provided by Gtk itself, so no change is required in the
New module files handling
Some Gtk modules (GdkPixbuf loaders and IM modules) will only be seen
by Gtk if listed in a "module file" listing meta-information of the
module along with its pathname. In the past, the postinst/postrm would
generate such files below /etc/gtk-2.0, and for the installer a
pre-generated /etc/gtk-2.0/gdk-pixbuf.loaders was shipped (but was
empty due to #382435).
With the new module handling, the module file is generated at build
time and the runtime shared library will read all files below
/usr/lib/gtk-2.0/2.10.0/loader-files.d and /immodule-files.d as well as
the old locations for backward compatibility.
No immediate change is required in the installer, but it is recommended
that you drop the /etc/gtk-2.0/gdk-pixbuf.loaders file (which you
started shipping in a separate udeb due to #382435) when switching to
Gtk 2.10. The Gtk udeb now has this module file instead:
(If you do maintain Gtk modules packaged outside of Debian, or Gtk
modules udebs which I didn't see, please contact me for full
Development based on Gtk-DirectFB headers and libraries
The pkg-config files for a Gtk build configured with a Gdk DirectFB
backend differ from those configured with a X11 backend. The
gdkconfig.h header also differs, and this header is included indirectly
when you use the Gtk headers.
Hence, packages building against libgtk-directfb-2.0-dev should set
appropriate CFLAGS and PKG_CONFIG_PATH.
To my knowledge, no package is built against libgtk-directfb-2.0-dev,
cdebconf is the only package built against libgtk+2.0-directfb-dev
(which is the flavor of Gtk maintained by debian-boot@), and hence no
package is affected by this change, but it should taken care of when
switching cdebconf to build against libgtk-directfb-2.0-dev.
(The pkg-config files from the directfb flavor not conflicting with
the standard pkg-config files of the X11 flavor are still shipped for
backwards-compatibility, but it is recommended not to use them.)
Due to the addition of printing support in Gtk, it now requires a
libcairo built with PS and PDF support. This wasn't the case of the
DirectFB flavor of libcairo until version >= 1.2.4-2. You need
libcairo-directfb2 >= 1.2.4-2, currently only available from
experimental, to use the DirectFB flavors of the Gtk 2.10 packages
(i.e. libgtk-directfb-2.0-0 and the Gtk udeb).
People wanting to use the udebs need to be careful and check the
version of libcairo used in their g-i builds. Gtk will not pull a high
enough libcairo-directfb2 by default. (This is #387289.)
This is also an important point to consider for unstable/testing
migration of Gtk 2.10, as this is the last missing build-dep in
On request of the installer team, the pixmap engine was added to the
Engines do not require a module file, no change is needed in the
Loïc Minier <firstname.lastname@example.org>