[Debian GNUstep maintainers] Bug#605565: Reopen Bug#605565: gnustep-base-runtime still fails to remove/upgrade if gdomap is not running

[Yavor Doganov]

On Thu, Dec 09, 2010 at 11:52:03PM +0100, Axel Beckert wrote:
> Yavor Doganov wrote:
> > Any idea what's the right approach to fix this problem?
> 
> Two ideas come to my mind:
> 
> 1. Ignoring the exit code of the init.d script in the prerem.

Something like:

...
pgrep -x gdomap || exit 0

#DEBHELPER#
...

?

This would solve the issue, I think, and I don't anticipate any
negative effects.  However, as it looks like a "dirty" solution, I'm
somewhat suspicious and not very keen to implement it immediately...
Any advice/comments appreciated.

> 2. AFAIK the maintainer scripts know if the package is just removed or
>    upgraded, so maybe calling it in postinst instead of prerm only if
>    the package is upgraded.

No, the daemon must be stopped in prerm, particularly when doing the
lenny->squeeze upgrade, because there's a soname change in the
library.

> BTW: Do you know if that problem is present in Lenny, too?

Yes, definitely.  (Dist-)upgrading from lenny with the gdomap daemon
not running for some reason would reveal the same issue you
encountered.

> Well, maybe you can put some code handling this issue specificly
> before the debhelper snippets and care that they are not run in case
> this special case occurs.

See above, that pgrep check is the best I could think of (the procps
package is guaranteed to be installed on hurd-* and kfreebsd-* as
well).  But I'm not sure, looks more like sweeping the problem under
the carpet to me.