[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]

Alan Jenkins wrote:
> 1. My hopes had been raised to see something for this issue in Debian
> 10.x.

Sure, if the stable release managers approve it.  It has to be fixed
in unstable/testing first.

> Even if it was basically limited to documentation in NEWS and
> the release notes.

Adding a debian/NEWS entry is a good thing indeed.

> This would raise the question, would you use this approach for a
> backport for 10.x?  Or would that require something different?

Yes, but a regular stable update, not a backport.

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

I guess we can check if the version being upgraded from is
1.26.0-4+deb10u1 (provided the release team accepts the stable update)
and skip the deletion if that is the case.  Or just don't bother as
there will be a NEWS entry anyway.

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

Very few, I would guess.

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

Sounds reasonable.  This should have been done 1.25.1-1, now there is
no reliable way to check whether the user wants it enabled or not.
It's all guesswork.

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

No, people are doing unattended upgrades so prompting should be
restricted to really important things (and should provide a default
choice anyway).

> 4. The implementation might be improved.

Certainly.

> 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= :-).

TBH, I haven't thought about that at all, I just prefer the other way
as it is more readable.

> 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

I'll use that, thanks.