[Debian GNUstep maintainers] Extending config.mk

[Yavor Doganov]

These days it seems fashionable to minimize debian/rules as possible,
so I suggest to add

messages := yes

to gnustep-make/debian/addons/config.mk.

That way, each package can stop defining it explicitly if it simply
includes config.mk.  The only problem I see with this change is that
we'll get verbose output for all other targets like install/distclean
and we generally don't need that.  (I used to define messages=yes
during install for a specific package long time ago when I was chasing
an obscure gnustep-make bug.  It turned out to be a bug in the
makefile; upstream was using a private variable that was either
removed or changed semantics in a new gnustep-make release.)

IMHO a better approach would be to define in config.mk:

gnustep_build_cmd := dh_auto_build -- $(optim) messages=yes \
  		       $(shell dpkg-buildflags --export=cmdline)

For most packages, it would be sufficient to do:

override_dh_autobuild:
	$(gnustep_build_cmd)

We can drop the override entirely if GNUstep Make is fixed to honor
environment variables (on my TODO list, along with other enhancement
proposals that I have to discuss on gnustep-dev@ first).

Hubert had the vision that maintaining a GNUstep package shouldn't be
any different or harder than any other package, and that all
GNUstep-specific things should be wrapped in Debian-specific tool and
machinery that should work out of the box.  This was the idea of
gsdh_gnustep and the cdbs implementation, although gsdh_gnustep was
never finished.  CDBS works without major changes after all these
years, which is amazing.  (JFTR, I dislike CDBS very much but decided
not to migrate some packages to dh in order to test the GNUstep cdbs
stuff.)

When debhelper evolved to dh, initially I thought that we should
implement a specific "gnustep" debhelper buildsystem.  I no longer
share this opinion, because GNUstep packages need very few additional
things on top of the standard debhelper buildsystem and we should
attempt to implement them via config.mk.

I think we should kill gsdh_gnustep entirely, starting with the
horrible hack gs_make first.  Since the "debian" layout was added in
gnustep-make, the only *useful* job that gsdh_gnustep was doing was
for the core GNUstep packages.  But Eric changed them to use standard
dh files/tools and eliminated the ${gnustep:Depends} substvar.  I
think the core packages are more complex now, but that's just my
opinion and I fully agree that the added complexity of two packages is
worth it if we can get rid of the gs_* things.

WDYT?