Niels Thykier wrote:
> On Fri, 28 Jun 2024 23:14:32 +0300 Yavor Doganov <ya...@gnu.org> wrote:
> > Usertags: dh_gnustep-removal
> I do not understand the rationale. [...] At this point, 2/3 of all
> tools named `dh_<something>` are *not* part of debhelper.
I didn't realize there are so many.
> 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.
Hmm, apparently the plan was not well thought.
I wanted to change the behavior by writing a dh_bugfiles addition.
We want the GNUstep backend to be reported automatically so
gnustep-back will soon have a bug script which can be symlinked by any
package that depends on gnustep-gui. This addition will automatically
create the symlink (/usr/share/bug/$package ->
/usr/share/bug/gnustep-back-common) if it detects that gnustep-backN
is in depends and will add a versioned dependency via ${misc:Depends}
on the gnustep-back-common package containing the bug script.
But then I thought that such change in behavior might be too risky so
I came to the idea that writing another tool would be a better option.
And I couldn't come up with another name but gsdh_bugfiles (which
cannot have its dh_ counterpart as that's the debhelper dh_bugfiles).
So the dh_gnustep removal is mostly for consistency.
Perhaps the right thing to do is to follow your advice and close these
bugs; I am still undecided.
P.S. I see nothing wrong to implement this new ala dh_bugfiles
behavior within dh_gnustep with the appropriate NEWS entry and a
test rebuild of all GNUstep packages that use (gs)dh_gnustep.
