[Debian GNUstep maintainers] New dh_gnustep default behavior and new functionality

[Yavor Doganov]

With the next gnustep-make debian release (which will soon be in the
hands of tarzeau to review and upload) there will be changes in
(gs)dh_gnustep's default behavior and some extra functionality you can
rely from now onwards.

New default behavior
--------------------

For all packages with names ending with ".app", dh_gnustep will
install a bug-script symlink (/usr/share/bug/<package> or
/usr/share/bug/<package>/script if the package already has bug-presubj
or bug-control files) pointing to /usr/share/bug/gnustep-back-common
in order to report the GNUstep backend used when submitting bugs with
reportbug.  It will also add a versioned dependency on
gnustep-back-common via the ${misc:Depends} substvar.

Not that we get many reports, but quite often the first question asked
in our response is "Which backend do you use?", followed sometimes by
instructions how to obtain that information.  It will happen
automatically now (when apps are rebuilt, no matter with a sourceful
upload or binNMU).

If the package already has a bug script file, a warning is printed and
no action is taken in this regard (FWIW, there is no GNUstep package
with a bug-script; plopfolio.app has a bug-presubj).  For packages
with other names where having a bug-script symlink is desirable
(gnustep-examples, gnustep-dl2, to name a few), this can be achieved
by passing the --bug-script option.

By default, dh_gnustep will delete all stamp.make and dependencies
files it finds in package directories.  This is in the BUGS section of
dh_gnustep(1) but I consider it a bug (or at least an undesirable
effect) that we should try to fix upstream.  The type and number of
the files is recorded in the build log unless DH_QUIET is set:

...
gsdh_gnustep
	Deleted 38 stamp.make files in gnustep-examples.
...

The --no-cleanup option cancels this operation.

New functionality
-----------------

The --app option moves the app's resource bundle to /usr/share and
makes the necessary symlink.  This is not done by default as it would
make every app FTBFS.  All apps currently either do this manually in
debian/rules, or with .install/.links files.  The aim is to replace
stuff in a typical app's debian/rules:

override_dh_link:
	gsdh_gnustep
	dh_installdirs usr/share/GNUstep
	rm $(d_app)$(GNUSTEP_SYSTEM_APPS)/*.app/Resources/*.desktop
	mv $(d_app)$(GNUSTEP_SYSTEM_APPS)/Zipper.app/Resources \
	  $(d_app)/usr/share/GNUstep/Zipper.app
	dh_link /usr/share/GNUstep/Zipper.app \
	  $(GNUSTEP_SYSTEM_APPS)/Zipper.app/Resources

with

execute_before_dh_link:
        gsdh_gnustep --app

Alex told me he likes less typing, so here you go.  FWIW, this was
also in the BUGS section of the manpage.

The --app option does not handle the transition from directory to
symlink which is mandatory due to dpkg limitation.  It removes the
.desktop file generated by pl2link which we cannot use for various
reasons.

The --move-to=<package> option combined with --app is a special case
when the Resources directory (usually because of its large size) has
to be moved to an arch-indep package.  So using a real example:

override_dh_link:
ifeq (,$(filter lynkeos.app-common,$(shell dh_listpackages)))
	$(RM) $(d_app)$(GNUSTEP_SYSTEM_APPS)/Lynkeos.app/stamp.make
	$(RM) -r $(d_app)$(GNUSTEP_SYSTEM_APPS)/Lynkeos.app/Resources
else
	$(RM) $(d_app)$(GNUSTEP_SYSTEM_APPS)/Lynkeos.app/stamp.make
	$(RM) $(d_app)$(GNUSTEP_SYSTEM_APPS)/Lynkeos.app/Resources/*.desktop
	dh_installdirs -plynkeos.app-common usr/share/GNUstep
	mv $(d_app)$(GNUSTEP_SYSTEM_APPS)/Lynkeos.app/Resources \
	  $(d_com)/usr/share/GNUstep/Lynkeos.app
	dh_link -plynkeos.app-common /usr/share/GNUstep/Lynkeos.app \
	  $(GNUSTEP_SYSTEM_APPS)/Lynkeos.app/Resources
	sed --in-place 's/$$(MARKETING_VERSION)/$(marketver)/' \
	  $(d_com)/usr/share/GNUstep/Lynkeos.app/Info-gnustep.plist
endif

becomes:

execute_before_dh_link:
ifeq (,$(filter lynkeos.app-common,$(shell dh_listpackages)))
	$(RM) -r $(d_app)$(GNUSTEP_SYSTEM_APPS)/Lynkeos.app/Resources
	gsdh_gnustep
else
	gsdh_gnustep --app --move-to=lynkeos.app-common
endif

The sed call at the end should be moved to the already existing target
override_dh_fixperms-indep.  A detailed explanation of the above
snippet is included in the new dh_gnustep manpage, in the EXAMPLES
section.

I've spent most of the time working on this; the implementation is
non-canonical and potentially dangerous as it touches package dirs in
another package, and behaves differently in different scenarios (full
binary build, arch-all/arch-any build).  Use with great caution, and
always test arch-only and all-only builds.

The --game option (must be used with --app) does the same as --app and
additionaly moves the symlink to the executable from /usr/bin to
/usr/games.  So typical code for a single-binary game like:

override_dh_link:
	dh_gnustep
	mv $(d_app)/usr/bin/Gridlock $(d_app)/usr/games
	$(RM) -r $(d_app)/usr/bin
	rm $(d_app)$(GNUSTEP_SYSTEM_APPS)/*.app/Resources/*.desktop
	mv $(d_app)$(GNUSTEP_SYSTEM_APPS)/Gridlock.app/Resources \
	  $(d_app)/usr/share/GNUstep/Gridlock.app
	dh_link usr/share/GNUstep/Gridlock.app \
	  $(GNUSTEP_SYSTEM_APPS)/Gridlock.app/Resources

becomes:

execute_before_link:
	dh_gnustep --app --game

The --game option also works with --move-to so this opens the door to
packaging future GNUstep games with large data :).

The --no-move option cancels absolutely all move operations and is
incompatible with --app/--game/--move-to.

I've tested the new default behaviour thrice (when I implemented the
bug-script functionality, then with cleanup of the build artifacts and
finally when completing all the extra stuff) with the following
packages, which either invoke (gs)dh_gnustep from debian/rules, or use
it indirectly (via cdbs and our gnustep.mk):

aclock.app
adun.app
affiche
chess.app
cynthiune.app
etoile
fontmanager.app
gnustep-examples
gnustep-netclasses (cdbs)
gorm.app
gridlock.app
gtamsanalyzer.app
mpdcon.app
paje.app (cdbs, but also invokes gsdh_gnustep from debian/rules)
pantomime
poe.app
popplerkit.framework (cdbs)
preview.app
price.app
projectcenter.app
renaissance (cdbs)
rsskit
sbjson (cdbs)
sope
steptalk (cdbs)
systempreferences.app
talksoup.app
textedit.app
timemon.app
viewpdf.app
volumecontrol.app
zipper.app

All built successfully and by examining the logs and "dpkg -c/-I"
output I came to the conclusion that there is no regression.  But this
is my first ever encounter with the Camel language so bugs are likely.

P.S.  I'll close the bugs I filed recently regarding dh_gnustep's
      removal.