Package GTK 2 Modules Safely with dh_gtkmodules

You will finish with a checked decision about dh_gtkmodules: whether the helper is present, what it is meant to generate, and whether it should be in a GTK 2 package build. The installed manual belongs to libgtk2.0-dev version 2.24.33-4ubuntu1.1. On this machine the package installs the manual page but no executable, so the first useful result is an honest capability check.

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 may need the normal package-build permissions; do not use sudo merely to run this helper.

1. Check what is installed

Start with the package version, manual page and command lookup. These commands 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. Do not infer that an installed manual means that the corresponding helper is runnable. If command -v finds nothing, stop the runtime experiment here. Read the manual as documentation, not as proof that a missing binary can be invoked.

2. Read the helper's contract

Render the local manual in the terminal:

$ man dh_gtkmodules

The documented job is packaging-time work. It looks in the current package staging area for the versioned GTK module directory, adds the GTK binary ABI dependency to ${misc:Depends}, and writes package-named metadata when it finds GdkPixbuf loaders or GTK input-method modules. A loader file is named <package>.loaders; an input-method file is named <package>.immodules.

The -k option is the one helper-specific switch: it suppresses dependency generation in ${misc:Depends}. It does not mean "do not generate module indexes" and it does not make a missing staging directory appear.

Checkpoint: the helper is for a Debian package's temporary tree, not for your host's live GTK installation. Do not run it from an arbitrary source directory and expect it to configure GTK for users.

3. Check the source implementation before adding it to a build

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

Use a primary source page when you need to confirm that detail:

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

If you are working offline, the decisive local check is still whether the executable exists. If it is absent, a new dh_gtkmodules line cannot work in this build environment. If it is 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 printed by your package build tooling, 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 the package and architecture. A directory named loaders is not itself proof that your package contains a loader module, and a pre-existing .immodules file is not proof that 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 command shape from the manual is:

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

The warning and exact punctuation come from the upstream implementation and may differ in a vendor build. A zero exit status is not proof that a loader index was written. After the step, inspect the package 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. Before editing debian/rules, save the current file or make the change in version control. If a trial fails, remove only the line you added and rebuild from a clean staging tree. Do not delete system GTK module files as an attempted fix. If a test has polluted a package staging directory, run the package's normal clean target and verify the working tree before rebuilding.