[Debian GNUstep maintainers] Bug#1074452: timemon.app: dh_gnustep removal

[Niels Thykier]

On Fri, 28 Jun 2024 23:14:32 +0300 Yavor Doganov <yavor at gnu.org> wrote:
> Source: timemon.app
> Version: 4.2-3
> Tags: sid trixie ftbfs
> User: pkg-gnustep-maintainers at lists.alioth.debian.org
> Usertags: dh_gnustep-removal
> 

Hi Yavor

I am not affiliated with the package in question, so this is just a 
drive-by remark.

> This package uses dh_gnustep directly but dh_gnustep will be removed
> in the near future.  It is not part of debhelper so the program
> (script) name is misleading.
> 
> There is a /usr/bin/gsdh_gnustep symlink which currently points to
> /usr/bin/dh_gnustep; the plan is to leave only gsdh_gnustep which will
> be the real script.  So please make sure to invoke gsdh_gnustep
> directly in your debian/rules.
> 
> You can remove the build-dependency on gnustep-make straight away
> (lintian issues a warning if a dh_* command is in another package and
> the source package using it is not build-depending on it); the
> gsdh_gnustep symlink exists since the first time when (gs)dh_gnustep
> was implemented (gnustep-make/1.11.1-1) and is guaranteed to be
> available across all relevant Debian suites.
> 
> The severity of this bug will be promoted to "serious" as soon as the
> appropriate gnustep-make upload (removing dh_gnustep) is made to
> unstable as it will cause this package to FTBFS.
> 
> P.S.  Most probably I'll handle this myself when the time comes.
> 
> 


I do not understand the rationale. Plenty of third-party dh_X tools
exist and that is part of the debhelper eco-system that third-party 
tools call themselves `dh_X` despite not being part of debhelper itself. 
What is important is whether the scripts behaves like a debhelper tool. 
Given that dh_gnustep uses debhelper's `Dh_Lib` to parse options (etc.), 
then it is reasonable to assume it is "debhelper"-like enough. At this 
point, 2/3 of all tools named `dh_<something>` are *not* part of debhelper.

In other words, it seems unnecessary to me to rename the tool just to 
avoid the debhelper association - at least from the position I am 
looking. Obviously, I am not involved in any of this and it might still 
make sense to rename if the plan is to also change the behavior of the tool.

Best regards,
Niels