[Debian GNUstep maintainers] Bug#939119: closed by Yavor Doganov <yavor at gnu.org> (Bug#939119: fixed in gnustep-base 1.26.0-5)

[Yavor Doganov]

Control: reopen -1
Control: found -1 1.26.0-5

Alan Jenkins wrote:
> But now I can see the code laid out, I'm not sure the newly added
> preinst is doing anything.

You are right that it does nothing :-(

Oddly enough, I've been investigating this on a buster machine
(upgraded from stretch) where all symlinks were K.  It is quite
possible that I've disabled it manually with update-rc.d and I just
don't remember.  However, on a stretch machine not yet upgraded to
buster:

yavor at bogdana:~$ find /etc/rc?.d -name \*gdomap
/etc/rc0.d/K01gdomap
/etc/rc1.d/K01gdomap
/etc/rc2.d/S18gdomap
/etc/rc3.d/S18gdomap
/etc/rc4.d/S18gdomap
/etc/rc5.d/S18gdomap
/etc/rc6.d/K01gdomap
yavor at bogdana:~$ grep ^ENABLED /etc/default/gdomap 
ENABLED=no

> We only reset the symlinks - i.e. disable the init script - when the
> [S]tart symlink does not exist - i.e. the init script is already
> disabled?

Stupid me.

> If we don't have an ENABLED= line, because we already hit this bug,
> then I think we just don't have the information.  We have to make the
> choice.

Right.  And the default choice should be to disable the daemon.

> Either preserve the current enabled status, as I do above. Or
> check we don't have ENABLED=yes, then guess the user was in the
> "99.5%", and force the service to be disabled.

I prefer the latter.  How about this:

if [ "$1" = "upgrade" ]; then
    if dpkg --compare-versions "$2" lt 1.26.0-6; then
        if [ -f /etc/default/gdomap ]; then
            . /etc/default/gdomap
            if [ "$ENABLED" != "yes" ]; then
                find /etc/rc?.d -name "*gdomap" -delete
            fi
        fi
    fi
fi

IOW, if the user wants the daemon running, chances are that he has
already changed the default to ENABLED=yes and although it does
nothing from the buster version onwards, it seems likely that he has
preserved his modification to the /etc/default/gdomap file.