Comment 1 for bug 1820317

I took a look at this and found that:

a) firewalld root-unittests autopkgtests fail when using either iptables 1.6 or 1.8 in release due to https://bugzilla.redhat.com/show_bug.cgi?id=1601610 and the failure is: "2019-03-24 17:30:19 ERROR: COMMAND_FAILED: '/sbin/ipset add foobar 10.1.2.0/22' failed: ipset v6.38: Kernel support protocol versions 6-7 while userspace supports protocol versions 6-6".
b) firewalld smoke-with-recommends autopkgtests fail when using 1.8 in -proposed (this bug)
c) someone in the Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914694 claims that https://git.netfilter.org/iptables/commit/?id=947c51c95 resolves this issue. I took a look at backporting this and found that libnftnl requires 5 patches (which apply cleanly) and iptables needs at least 13 patches before the claimed fix can apply and 1 bug fix patch after. It seems that Debian is waiting for iptables 1.8.3 since the changes are so intrusive (I stopped at 13 patches because I found that I needed more and more earlier patches to support the new table and rule caching)
d) firewalld in 0.6.3-5 introduced the dependency on iptables 1.8.1 and dropped the recommends on ebtables. Dropping this and keeping iptables at 1.6 results in allowing smoke-with-recommends to pass and restores the 0.6.3-4 failing ipset behavior.
e) adjust iptables.postinst to use a lower update-alternatives priority such that iptables-legacy is used results in allowing smoke-with-recommends to pass and restores the 0.6.3-4 failing ipset behavior. We may want to reintroduce the Recommends in firewalld on ebtables so as not to mix ebtables-nft with iptables-legacy

Attempting to cherrypick all the patches to try to fix this is too regression-prone IME (indeed, there was one known regression with the patches; who knows how many more are lurking at the tip of upstream). I also don't want to take a git snapshot for similar reasons. I would much rather wait for upstream to release 1.8.3, much like Debian is.

This leaves us with 3 options:
a) leave 1.6 in disco and adjust the firewalld packaging to not require 1.8
b) adjust 1.8 in disco to prefer the legacy iptables commands instead of nft
c) keep everything as is and ignore the firewalld error. This is how Debian Buster is going to release

Since this represents a real bug in iptables, I think 'c' is out. While 'b' is an option, it is less well tested and I prefer 'a'. Once iptables 1.8.3 is out and/or Debian fixes 914694, then we can pull 1.8 into the archive. We will definitely want 1.8 in for 20.04 LTS.

I will remove 1.8 from disco-proposed and upload a firewalld with the adjusted Depends/Recommends, but someone else should look at the firewalld autopkgtest ipset regression.