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

[Alan Jenkins]

On 19/09/2019 13:09, Yavor Doganov wrote:
> 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.

You weren't the first person to suggest testing /etc/rc2.d/S??gdomap 
:-). I always think this stuff is confusing.  The important thing is to 
ask for people to test it :-).

>
>> 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.

1. My hopes had been raised to see something for this issue in Debian 
10.x.  Even if it was basically limited to documentation in NEWS and the 
release notes.  This would raise the question, would you use this 
approach for a backport for 10.x?  Or would that require something 
different?

umm, and if we do disable in 10.x, I have a bonus question.  Would we 
need some code to make sure we didn't disable a second time on upgrade 
to 11.x?


2. For my sake, I am very happy to see gdomap disabled on the next 
upgrade :-).

Our defaults already mean that if you rely on gdomap, you need to know 
that, and enable it. (And if you want network features, change 
GDOMAP_ARGS.  In a way, I think the docs make that sound like more 
hassle than it is).

My only caveat is if you backported this approach to 10.x, I don't know 
enough to guess exactly how many people will be annoyed.

I had another look regarding a clever automatic check we could use in 
the preinst script.  But I didn't come up with anything


3. Disclosure: I think this argument is not very strong:

> 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.

If you choose to see a three-way diff, and see the package wants to 
remove ENABLED=, I think it's just as plausible you would have let the 
package do that.

There might be a way to be really clever, although I do not advocate it 
at all. Provide an upgrade prompt, that checks ENABLED= but otherwise 
defaults to disabling gdomap.  If a gdomap user tends to do upgrades 
Fedora/PackageKit style, i.e. accept all the default prompts, that means 
they will likely have preserved the ENABLED=yes :-).  Non-gdomap users 
will get it disabled again.  At the cost of inflicting one more upgrade 
prompt on a lot of people.


4. The implementation might be improved.

> 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

I guess you did not prefer my super-cautious approach, sourcing the 
config file inside brackets so it uses a sub-shell, and does not import 
arbitrary variables from the file e.g. LD_PRELOAD= :-).

Anyway, in this more aggressive policy, I think it should remove the 
links even if /etc/default/gdomap does not exist.  I think that makes it -

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

# or without using a subshell

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


Thanks again for your hard work
Alan