#!/bin/sh

set -e

# When emacsen-common and add-ons are upgrading simultaneously,
# emacsen-common can be unpacked but not configured when an add-on's
# prerm runs. That causes the add-on's removal command to be skipped,
# which is wrong and can cause the upgrade to fail. For example
# https://bugs.debian.org/1106291
#
# For now, to ensure the removal commands are still run, remove all
# emacs flavors here, keeping track of which flavors are actually
# still installed in pending, and then restore them from the postinst,
# when emacsen-common is ready again.
#
# Normally, it would be unsafe to depend on emacsen-common files like
# this in the preinst, but our assumption for this mitigation is that
# since emacs flavors depend on emacsen-common and since they should
# have a installed/FLAVOR file if and only if they're "ready to go"
# (i.e. via their postinst configure), then the emacs-remove script
# will be available inside the loop.

mkdir -p /var/lib/emacsen-common/state/flavor/pending
for flavor in /var/lib/emacsen-common/state/flavor/installed/*[!~]; do
    case "$flavor" in
        */installed/\**) break ;; # no flavors
    esac
    flavor="$(basename "$flavor")"
    echo "Removing emacsen flavor $flavor during emacsen-common upgrade" 1>&2
    /usr/lib/emacsen-common/emacs-remove "$flavor"
    touch "/var/lib/emacsen-common/state/flavor/pending/$flavor"
done

# The emacsen-common package is a special case; we can't call
# emacs-package-install from here since the new version hasn't been
# unpacked yet, so just do the important bit that it would have done.
installed_state_dir=/var/lib/emacsen-common/state/package/installed
if test -d "$installed_state_dir"
then
  rm -f "$installed_state_dir"/emacsen-common
fi

# Automatically added by dh_installdeb/13.24.2
dpkg-maintscript-helper rm_conffile /etc/emacs/site-start.d/00debian-vars.el 3.0.3\~ emacsen-common -- "$@"
dpkg-maintscript-helper rm_conffile /etc/emacs/site-start.el 3.0.3\~ emacsen-common -- "$@"
# End automatically added section