Comment 13 for bug 1850933

Testing on the PPA confirmed that this would change the ordering but not trigger the disable of mod-php7.2 as I expected.
Here the ordering from the log:
$ grep "mod-php7" apt.log
Removing libapache2-mod-php7.2 (7.2.24-0ubuntu0.19.04.1) ...
Package apache2 is not configured yet. Will defer actions by package libapache2-mod-php7.2.
Selecting previously unselected package libapache2-mod-php7.3.
Preparing to unpack .../0-libapache2-mod-php7.3_7.3.11-0ubuntu0.19.10.2~ppa3_amd64.deb ...
Unpacking libapache2-mod-php7.3 (7.3.11-0ubuntu0.19.10.2~ppa3) ...
Setting up libapache2-mod-php7.3 (7.3.11-0ubuntu0.19.10.2~ppa3) ...
libapache2-mod-php7.3: php7.2 module already enabled, not enabling PHP 7.3

It was removed first, but not deconfigured I guess.

It is even worse, as php7.2 is still configured (in /etc) but no more installed (the .so file).
Therefore the apache2 restart fails with a proper message about it.
One might say this is nice as it is the safer approach but there must be something better.

I confirmed my next assumption, only a "purge" action would disable the 7.2 module.

# Automatically added by dh_apache2/UNDECLARED
if [ "$1" = "purge" ] ; then
        if php_enable; then
                if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
                        . /usr/share/apache2/apache2-maintscript-helper

                        for conf in php7.2 ; do
                                apache2_invoke dismod $conf || exit 1
                        done
                fi
        fi
fi
# End automatically added section

This should affect Debian upgrades e,g, oldstable 7.0 -> stable 7.3 as well.
We might even want to discuss it there if we'd want to go a joint path or if there are drawbacks.

It seems the solution to this isn't too complex, maybe just another postinst snippet, but the impact suggests that there on't be an SRU for it. OTOH we should clearly get a proper hold of this before 20.04 is finished.

But for now let me raise it with the team first.