Hide Forgot
please consider splitting out a iptables-libs subpackage with: /usr/lib*/libip4tc.so* /usr/lib*/libip6tc.so* /usr/lib*/libiptc.so* We would like to minimize the container image size and iptables pulls in a lot of other deps: https://harald.fedorapeople.org/rawhide-20160401-systemd/Tree-iptables.svg e.g. systemd only needs libiptc
"iptables-libiptc" might be a better name though
note that systemd-networkd/systemd-nspawn (i.e. the iptables-using components of systemd) only need libiptc itself, and not any of the modules, hence it would make sense to split out only libiptc without any of the modules in their own package, which would then just be 32K in size or so...
Adding an sub package for an unsupported and internal only library (see further down) would not be good in my opinion. I'd favor to move some extensions into an extensions sub package to get the libnetfilter_conntrack and libnfnetlink dependency out of the the base package. Additionally with the latest iptables version it would also be needed to create a compat sub package to keep the dependencies out. libiptc does not have a stable API, not even a real so version. Excerpt form http://www.netfilter.org/documentation/FAQ/netfilter-faq-4.html#ss4.5 4.5 Is there an C/C++ API for adding/removing rules? The answer unfortunately is: No. Now you might think 'but what about libiptc?'. As has been pointed out numerous times on the mailinglist(s), libiptc was _NEVER_ meant to be used as a public interface. We don't guarantee a stable interface, and it is planned to remove it in the next incarnation of linux packet filtering. libiptc is way too low-layer to be used reasonably anyway. We are well aware that there is a fundamental lack for such an API, and we are working on improving that situation. Until then, it is recommended to either use system() or open a pipe into stdin of iptables-restore. The latter will give you a way better performance. -- This means that there is no upstream support for libiptc usage and absolutely no guarantee that the interface will be similar or the same in a newer version. If systemd build breaks because of libiptc incompatibilities than there will also be no support from upstream. It will not even be possible to add fixes without breaking the iptables tools.
I thought about this some more an there is now an iptables-libs sub package containing libxtables and libip*tc with an extra description about libip*tc limitations.
Fixed in rawhide in package iptables-1.6.0-1.fc25
Thanks! :-)
Please note that there might be packages that depended on iptables always being installed, which no longer applies. You should probably chase these down and tell them they now need to explicitly depend on iptables. Example bug: 1327809