[debian-mysql] Bug#675250: mysql-server-5.5: don't stop server in postrm if another version is already running

[Julian Gilbey]

Package: mysql-server-5.5
Version: 5.5.23+dfsg-2

When purging an old version of mysql-server (5.1 in this case), the
purge stopped the new server - oops!

This would seem to be incorrect behaviour.  The postrm code currently
reads:

[...]
case "$1" in
  purge|remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
    if [ -n "`$MYADMIN ping 2>/dev/null`" ]; then
      stop_server
      sleep 2
    fi
  ;;
[...]
esac

#
# - Do NOT purge logs or data if another mysql-sever* package is installed (#307473)
# - Remove the mysql user only after all his owned files are purged.
#   
if [ "$1" = "purge" -a ! \( -x /usr/sbin/mysqld -o -L /usr/sbin/mysqld \) ]; then
   [...do stuff on real purge of all mysql servers only...]
fi
[...]


It is unclear why the server is being stopped in the postrm in most of
the listed cases, whereas a careful check before purging data files
etc. is carried out.  Instead, the server should be stopped in the
prerm script, as by the time the postrm script is called in most
normal circumstances, the package's files have already been removed
from the system.  In detail, following section 6.6 of the policy
manual, it would seem that the following would be sensible:

PRErm: when called with

  upgrade, deconfigure, remove: one or more of these are called
  immediately before an upgrade or removal (and deconfigure/remove in
  the case of upgrading to a new package eg 5.1 -> 5.5), so these
  should stop the server

  failed-upgrade: the old prerm failed, this attempts to fix the
  situation, and should allow the upgrade to proceed, so no server
  starting/stopping should be done in this case


POSTrm: should never touch the server's state; when called with

  failed-upgrade, abort-upgrade: an upgrade failed at some point, but
  the old postinst will also be called with abort-upgrade, so this
  should not start or stop the server

  abort-install: something went wrong with the new-preinst install
  invocation, so this should not start or stop the server (if
  anything, perhaps stop the server if it's running); the package will
  be left in a Half-Installed or Config-Files state

  upgrade: this is called just before old files are removed; since the
  server was stopped earlier, this should not do anything

  disappear: unlikely to ever be called for this package, but even if
  it is, it shouldn't do anything with the server state

  purge, remove: the server should already have been stopped by the
  prerm script, so these should do nothing to the server


On the other hand: postinst, when called with

  abort-upgrade, abort-deconfigure, abort-remove: an upgrade failed
  very early, so these should restart the server  


HTH,

   Julian