Package GTK 2 Modules Safely with dh_gtkmodules

Inherit an old debian/rules file and you may find dh_gtkmodules still called long after GTK 2 packaging moved on. The installed manual belongs to libgtk2.0-dev version 2.24.33-4ubuntu1.1, and on this machine the package ships that manual page but no executable at all. That gap is the whole story here: the first useful result is an honest capability check, not a live run.

Allow about fifteen minutes. You need a shell and a Debian packaging tree if you are testing a real package. The inspection commands are unprivileged; building or installing a package can write outside your working directory and needs the normal package-build permissions, not sudo for this helper specifically.

1. Check what is actually installed

Start with the package version, manual page and command lookup. These only read system state:

$ dpkg-query -W -f='${Package} ${Version}\n' libgtk2.0-dev:amd64
libgtk2.0-dev 2.24.33-4ubuntu1.1
$ command -v dh_gtkmodules || echo 'dh_gtkmodules executable not found'
dh_gtkmodules executable not found
$ test -r /usr/share/man/man1/dh_gtkmodules.1.gz && echo 'manual page present'
manual page present

Your version and command path may differ. An installed manual does not mean the corresponding helper is runnable: if command -v finds nothing, stop the runtime experiment here and read the manual as documentation only.

2. Read the helper's contract

Render the local manual in the terminal:

$ man dh_gtkmodules

• What it looks for. The documented job is packaging-time work: it scans the current package staging area for the versioned GTK module directory.
• What it adds. It adds the GTK binary ABI dependency to ${misc:Depends}.
• What it writes. It writes package-named metadata when it finds GdkPixbuf loaders or GTK input-method modules: a loader file named <package>.loaders, an input-method file named <package>.immodules.
• What -k does. The only helper-specific switch suppresses dependency generation in ${misc:Depends}. It does not stop module-index generation and it does not conjure a missing staging directory.

3. Check the source before adding it to a build

This helper has an awkward version boundary. The Debian source implementation behind the published GTK 2 packaging code marks dh_gtkmodules as deprecated, because the work is now handled by triggers: it prints a warning and exits successfully. That is newer evidence than the broad manual description, so treat the manual as the contract but check the source and package changelog before adding a new call to a maintained rules file.

$ xdg-open 'https://sources.debian.org/src/gtk%2B2.0/2.24.31-2/debian/dh_gtkmodules.in'

Working offline? The decisive local check is still whether the executable exists. Absent, a new dh_gtkmodules line cannot work in this build environment. Present, run its help or the package's existing build sequence in a disposable build directory and capture the warning before changing packaging metadata.

4. Inspect a package staging tree without changing it

For a real package, replace DEB_TMP with the path your package build tooling prints, then inspect the GTK module directories. These are ordinary read-only commands:

$ DEB_TMP='debian/tmp'
$ find "$DEB_TMP" -type d \( -path '*/gtk-2.0/*' -o -name loaders -o -name immodules \) -print
$ find "$DEB_TMP" -type f \( -name '*.so' -o -name '*.loaders' -o -name '*.immodules' \) -print

The exact paths depend on package and architecture. A directory named loaders is not proof that your package contains a loader module, and a pre-existing .immodules file is not proof this helper created it. Check the package's install rules and the staged files together.

5. Test only in a disposable package build

Do not test against /usr/lib, /usr/share or a deployed package. Copy the source tree or use the normal clean build directory, then run the package's documented build command. If the helper is available, the manual's command shape is:

$ dh_gtkmodules
dh_gtkmodules: warning: deprecated, everything is handled by triggers now.

The warning wording comes from the upstream implementation and may differ in a vendor build. A zero exit status is not proof that a loader index was written, so inspect the staging area and generated substitution data, then build the package and examine its contents:

$ find debian/PKGNAME -type f \( -name '*.loaders' -o -name '*.immodules' \) -print
$ dpkg-deb -c ../PKGNAME_VERSION_ARCH.deb | grep -E '\.(loaders|immodules)$'

Replace PKGNAME and the package filename with values from your tree. If the helper is absent or only emits the deprecation warning, follow the current package build system and trigger-based handling rather than copying old packaging instructions.

6. Recover from a mistaken packaging change

Adding a helper call changes build metadata, not the running desktop. Save the current file or make the change in version control before editing debian/rules. If a trial fails, remove only the line you added and rebuild from a clean staging tree.