Comment 15 for bug 1774120

> Why is the importance set to low here?

I set it to low because this bug will only happen AFAICT on WSL. It will always happen there, but on WSL there is no use for ebtables (since it doesn't work there, IIUC). So the major impact is 'apt upgrade' fails, but users can easily work around that by marking ebtables as held to apt, as comment 2 states.

> what if a user has a much older version of the package and the upgrade in prerm really fails?

Currently (and for all previous pkg versions), the only prerm action is what dh_installinit adds by default, which is a call to stop the ebtables service.

The ebtables.init service script, when called to 'stop', does a save (if EBTABLES_SAVE_ON_STOP) as well as a clear.

If the 'save' and/or 'clear' operations fail, that does not matter w.r.t. upgrading ebtables, because those operations manipulate the in-kernel ebtables entries. The new ebtables package provides only userspace programs to control those tables.

Also note that as I mentioned in the SRU template info, the RPM version of ebtables does exactly what I just mentioned; it totally ignores the return value of the ebtables stop action:

%preun
if [ $1 -eq 0 ]; then
 /sbin/service ebtables stop &>/dev/null || :
 /sbin/chkconfig --del ebtables
fi

Because older versions of ebtables will *always* fail during upgrade (or remove!) on WSL, the new prerm script needs to always ignore 'upgrade-failed' errors, unless we want to add a specific test that it's running on WSL (like checking for -EPROTONOSUPPORT from socket()). However, that seems overly complicated and fragile, and I see no reason that we shouldn't simply ignore the 'upgrade-failed' error based on what we know happens during prerm 'upgrade'.

If you prefer a simpler change, I can re-upload (to cosmic and SRU) with the ebtables.init changes removed, and only a modified ebtables.prerm file to simply ignore both 'upgrade' and 'upgrade-failed' errors (at the appropriate points in the prerm script).