Bug 1323161
| Summary: | iptables-libiptc | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Harald Hoyer <harald> |
| Component: | iptables | Assignee: | Thomas Woerner <twoerner> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | jpopelka, puiterwijk, twoerner |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-04-13 17:23:35 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1323209 | ||
|
Description
Harald Hoyer
2016-04-01 12:21:24 UTC
"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 |