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.
