DH_GNUSTEP(1)

📦
version 2.9.3 · 3 versions
, in ubuntu resolute, ubuntu stonking

💖 dh_gnustep(1) — the manual page, but make it cute 💖

okay bestie, gather round, because this one is genuinely iconic and I need you to understand it. This is dh_gnustep, and the whole vibe is: it does GNUstep-specific stuff for your Debian package. Think of it as the friend who comes over, reorganizes your entire room, and somehow also fixes your dependencies. 🦋

✨ NAME ✨

dh_gnustep — performs various actions for GNUstep packages ✨

(that's it. that's the name. but the actions? ma'am. we'll get there.)

🌸 SYNOPSIS 🌸

dh_gnustep [debhelper options] [--app] [--appsupport] [--bundle]
[--bundle-dir=directory] [--bug-script] [--game] [--move-to=package]
[--no-cleanup] [--no-move]

so you run it, you throw some flags at it, it does stuff. very demure, very mindful.

👑 DESCRIPTION 👑

dh_gnustep is a little program built on top of debhelper(7), and its whole job is doing the GNUstep-specific glow-up on your package. We're talking: moving files around in the GNUstep hierarchy so they land in Filesystem Hierarchy Standard (FHS)-compliant locations (slay, policy compliance 💅), adding bug-script symlinks for GNUstep applications, yeeting some build system artifacts, and adding extra dependencies to the packages that need them.

now. the GNUstep directories have names so long they'll wrap like three times on a normal terminal, and honestly reading that is giving headache energy. so for brevity (and for your eyeballs), the standard GNUstep variables get used as placeholders like this:

  • GNUSTEP_SYSTEM_LIBRARY → /usr/lib/${DEB_HOST_MULTIARCH}/GNUstep
  • GNUSTEP_SYSTEM_HEADERS → /usr/include/${DEB_HOST_MULTIARCH}/GNUstep
  • GNUSTEP_SYSTEM_APPS → /usr/lib/${DEB_HOST_MULTIARCH}/GNUstep/Applications
  • GNUSTEP_SYSTEM_APPLICATION_SUPPORT → /usr/lib/${DEB_HOST_MULTIARCH}/GNUstep/ApplicationSupport
  • GNUSTEP_SYSTEM_BUNDLES → /usr/lib/${DEB_HOST_MULTIARCH}/GNUstep/Bundles
⚠️ Timing matters, bestie. dh_gnustep must be run after dh_bugfiles(1) but before dh_link(1). The classic move is an override_dh_link target — but do not forget to still call dh_link(1) as the last command in the recipe. This is mandatory, no cap, because that's what makes the created links policy-compliant. If you wanna dodge that extra step entirely, use the execute_before_dh_link target instead. 🎀

so. here's everything this program changes (and psst — every single move operation can be cancelled with the --no-move option, keep that in your back pocket):

🗂️ the changes it makes

  • arch-indep directories: Moves architecture-independent directories in GNUSTEP_SYSTEM_LIBRARY over to /usr/share. 🏠
  • library resources: Moves library resources (GNUSTEP_SYSTEM_LIBRARY/Libraries) to /usr/share/GNUstep/Libraries.
  • frameworks: Moves framework headers to GNUSTEP_SYSTEM_HEADERS/Frameworks and framework resources to /usr/share/GNUstep/Frameworks.
  • applications: Moves application resource bundles to /usr/share/GNUstep. Not done by default — you gotta ask for it with the --app option.
  • application support: Moves application support (GNUSTEP_SYSTEM_APPLICATION_SUPPORT) bundles' resources to /usr/share/GNUstep. Not done by default — you gotta ask with the --appsupport option.
  • bundles: Moves bundles' resources (bundles live at GNUSTEP_SYSTEM_BUNDLES by default) to /usr/share/GNUstep. Not done by default — you gotta ask with the --bundle option. And if your bundles live somewhere non-standard, the --bundle-dir option has you covered. 🧺
  • bug-script symlinks: By default, dh_gnustep installs a bug-script symlink for any package whose name ends with .app, and that symlink points to /usr/share/bug/gnustep-back-common. Why? So that the system and user GNUstep backends get reported as package-specific info to the BTS when someone files a bug. It'll also add the appropriate dependency (through the ${misc:Depends} substitution variable). 💌

Important note: dh_gnustep does not handle any other bug files, and it expects dh_bugfiles(1) to have already finished its job — that's how it knows whether the bug-script symlink needs to be installed as /usr/share/bug/package/script (which happens when there are bug-control or bug-presubj files). If it detects an existing bug script, it'll emit a warning, because a package can only have one bug-script file. In that situation the only solution is to integrate the contents of /usr/share/bug/gnustep-back-common into the existing script. no shortcuts, sorry. 😭

  • build system artifacts: By default, dh_gnustep deletes stamp.make files — those are created and (unfortunately) installed by gnustep-make for many project types. Same energy: it also deletes the dependencies files created and installed for GNUstep documentation projects. The number and type of deleted files get recorded in the build log if DH_QUIET is not set. 🧹
  • additional dependencies: For packages that provide files in either GNUSTEP_SYSTEM_LIBRARY or GNUSTEP_SYSTEM_HEADERS, dh_gnustep automatically adds the necessary dependency for the multiarch layout (again, via the ${misc:Depends} substitution variable). it just does that. auto. ✨

🎀 OPTIONS 🎀

dh_gnustep takes all the usual debhelper(7) options plus some special ones of its own. And listen — if you use any of the options below, make sure you build-depend on gnustep-make (>= 2.9.2-2) if that version isn't already satisfied in the current stable/oldstable release. Some options were only implemented in later releases, and that's documented below, so read carefully bestie 🫶

  • --app — Move "Resources", aka the resource bundle of a GNUstep application (GNUSTEP_SYSTEM_APPS/Foo.app/Resources), to the architecture-independent /usr/share/GNUstep/Foo.app, and make the necessary symlink. The automatically generated .desktop file gets deleted. If the binary package contains more than one app, each one is processed independently.
⚠️ Care needed!! Some apps sneak architecture-dependent files into their resource bundle. 😬 And another thing you really need to pay attention to: if this is an existing package that does not have its resources moved to /usr/share, you need a maintscript, because dpkg will not switch a directory to a symlink (or vice versa). dh_gnustep does not handle that for you — go see dpkg-maintscript-helper(1).

This option is incompatible with --no-move, and for multi-binary packages it sometimes should be used together with the appropriate -p option.

  • --appsupport — Move the "Resources" directories of all bundles found in GNUSTEP_SYSTEM_APPLICATION_SUPPORT to /usr/share, as subdirectories of the parent directory. So if the package ships several bundles under GNUSTEP_SYSTEM_APPLICATION_SUPPORT/Palettes, they get moved as subdirectories into /usr/share/GNUstep/Palettes. 🎨

Heads up: bundles' resources sometimes contain architecture-dependent files, and in that case the best approach is to move the architecture-independent files manually.

This option was introduced in gnustep-make/2.9.2-3, and just like --app, it is incompatible with --no-move.

  • --bundle
  • --bundle-dir=directory — Move the "Resources" directory of all bundles found in GNUSTEP_SYSTEM_BUNDLES (or an alternative directory under GNUSTEP_SYSTEM_LIBRARY if the --bundle-dir option is specified) to /usr/share. If the package installs bundles in a subdirectory, that same subdirectory gets created under /usr/share/GNUstep. 📦

Introduced in gnustep-make/2.9.2-4, and it is incompatible with --no-move. Alsooo, --bundle and --bundle-dir are mutually exclusive. So if your package installs bundles in the standard Bundles directory and in some other non-standard directory, you're gonna have to run dh_gnustep twice with different arguments if you need to move all of the resource bundles. two runs, one goal. 💅

  • --bug-script — Install the bug-script symlink for the package even if its name does not end with .app. Typically you'd do this for apps that, for some reason, get installed alongside tools or other stuff inside a package with a different name (like gnustep-examples or gnustep-dl2). It can also be done for GUI bundles, themes, palettes, etc. You probably wanna reach for the -p option too here, otherwise dh_gnustep will add bug script symlinks for all binary packages. 🐛
  • --game — This option must be used together with --app. It does everything --app does (as described above), and additionally moves the symlink to the executable from /usr/bin to /usr/games. And if /usr/bin ends up empty afterwards, the directory gets deleted. 🎮
  • --move-to=package — This option must be used together with --app, --appsupport or --bundle/--bundle-dir (or any combination of those) . Here's the breakdown:
    • If --app is specified, move the resource bundle of an application to another architecture-independent package.
    • If --appsupport is given, move the "Resources" directories of all bundles found in GNUSTEP_SYSTEM_APPLICATION_SUPPORT to /usr/share/GNUstep in the specified package.
    • If --bundle is specified, move the "Resources" directories of all bundles in GNUSTEP_SYSTEM_BUNDLES (or an alternative directory if --bundle-dir is used) to /usr/share/GNUstep in the specified package.

And now the fine print, because this one bites. If --app, --appsupport and --bundle are used together, all resource bundles get moved into the package named by the option's argument — there is no way to split them across different packages. The current implementation will handle more than one app per binary package, but it will fail with a multi-binary source package containing more than one .app binary package. Likewise, if the package contains more than one ApplicationSupport directory, they'll be processed independently as expected, but the build is likely to fail if they live in different binary packages. 😭

Use with caution, fr fr — go check the EXAMPLES section for working examples.
  • --no-cleanup — Do not delete stamp.make and dependencies files. 🧼🚫
  • --no-move — Do not perform any move operations. And guess what — setting the DEB_GNUSTEP_NO_MOVE environment variable to a non-empty, non-zero value does the exact same thing. ✨

🌈 EXAMPLES 🌈

Bestie, these are the real ones — copy-paste energy, no cap. 💅

one — the "we already handled it, don't touch my files" move

execute_before_dh_link:
        dh_gnustep -pgnustep-dl2 --no-move --bug-script
        dh_gnustep --remaining-packages

So like, for the gnustep-dl2 package you do not move any files, okay, because that's already handled manually by someone (respect 🫶). But you do install a bug-script symlink, because that package has an application and a Gorm palette in it. Two for one, iconic.

two — relocate the resource bundle

execute_before_dh_link:
        dh_gnustep --app --move-to=lynkeos.app-common

This one moves the lynkeos.app resource bundle over to the architecture-independent package lynkeos.app-common. Slay. ✨

three — the game edition 🎮

override_dh_link:
        dh_gnustep --app --game
        dh_link

What this does: move the app's resource bundle to /usr/share, and move the symlink to the executable from /usr/bin to /user/games. Then — assuming the binary package name ends with .app — it creates a bug-script symlink pointing at /usr/share/bug/gnustep-back-common. And finally? It deletes the stamp.make file from the app bundle. Clean up, periodt. 🧹

Ngl, that /user/games path is exactly what the page says, so we keep it exactly, bestie. Character for character. 💅

four — the big conditional one (iykyk)

execute_before_dh_link:
ifneq (,$(filter gnustep-gui-runtime,$(shell dh_listpackages)))
        dh_gnustep -pgnustep-gui-runtime --app \
          --bundle-dir=ColorPickers --move-to=gnustep-gui-common
        dh_gnustep --remaining-packages
else
        dh_gnustep --app --bundle-dir=ColorPickers \
          --move-to=gnustep-gui-common
endif

Okay so here's the tea ☕: this moves the resource bundles of two apps and the resources of all the ColorPickers' bundles to /usr/share, inside the gnustep-gui-common package.

And the lil detail that makes me feral — dh_gnustep will automatically figure out that the package they're being moved from is gnustep-gui-runtime, so you do not need to use debhelper's -p option. Not me being obsessed with automation. 😭

The conditional is only there to support full builds, so that the symlinks get created in the gnustep-gui-runtime package. That's it, that's the whole reason. 🎀

💀 BUGS 💀

  • Should implement -X option. (It just… hasn't yet. A little mystery, a little main character flaw. 🙈)
  • Should do something with Java classes — make a jar file and move from Library/Libraries/Java to /usr/share/java — to comply with Java policy.

👑 CONFORMS TO 👑

🦋 SEE ALSO 🦋

Important vibe check: this program is not part of debhelper. It's its own thing, and honestly? Good for it. ✨

💖 AUTHORS 💖

  • Hubert Chan <uhoreg@debian.org>
  • Yavor Doganov <yavor@gnu.org>

And that's the whole page, bestie — scroll's done. This beauty was rendered by perl v5.40.1 and it's dated 2025-09-23, aka the day this manual page said "here for a good time AND a long time." 🫶🌸 Go forth and package your GNUstep stuff, you absolute icon. 💜

📦 where this page comes from