Dear Maintainer,

When removing the ifupdown package, for example if one replaces it with
ifupdown2, the premrm script will execute a `systemctl stop` to the
'networking.service'. If one is connect to the host over network (e.g.,
SSH), the connection is broken during this removal/replacement.

This is really no ideal, especially if one has no other access to this
host available.

Simple reproducer could be:
# apt install ifudown2

It would be great if the stop of 'networking.services' would be avoided,
similar to how the start on upgrade or installation is avoided.  I'd
expect that such deep network changes are only fully applied
automatically on the next reboot, or by a manual triggered process.

I reported this as important, even if the description from `reportbug`
may not fully match that, but I still found me in a bit troubling
situation when I encountered this, so IMO it's justified - but feel free
to adjust as deemed right, I'm no maintainer after all :)

thanks & cheers,
Thomas
--- up and down scripts installed:
/etc/network/if-down.d:
total 4
-rwxr-xr-x 1 root root 800 Apr  1  2019 postfix

/etc/network/if-post-down.d:
total 8
lrwxrwxrwx 1 root root   29 Jan 28  2019 bridge -> /lib/bridge-utils/ifupdown.sh
-rwxr-xr-x 1 root root 1714 Sep 27  2016 ifenslave
-rwxr-xr-x 1 root root  762 Jul 15 18:37 vlan

/etc/network/if-pre-up.d:
total 16
lrwxrwxrwx 1 root root   29 Jan 28  2019 bridge -> /lib/bridge-utils/ifupdown.sh
-rwxr-xr-x 1 root root  344 Jun 30  2016 ethtool
-rwxr-xr-x 1 root root 6298 Sep 27  2016 ifenslave
-rwxr-xr-x 1 root root 1163 Jul 15 18:37 vlan

/etc/network/if-up.d:
total 24
-rwxr-xr-x 1 root root  902 Jul 15 18:37 bridgevlan
-rwxr-xr-x 1 root root  409 Jul 15 18:37 bridgevlanport
-rwxr-xr-x 1 root root 1685 Jun 30  2016 ethtool
-rwxr-xr-x 1 root root 1741 Sep 27  2016 ifenslave
-rwxr-xr-x 1 root root  236 Jul 15 18:37 mtu
-rwxr-xr-x 1 root root 1117 Apr  1  2019 postfix

Followup, just re-checked a Debian Stretch installation. There it's all OK,
the offending lines are missing from the prerm script. This then seems to
be a regression which was triggered by the newer compat level 12 and the
different behavior of dh_installsystemd under that level.