iptables and patch-o-matic

[Matt Zimmerman]

On Fri, Jan 06, 2006 at 10:34:25AM -0600, Rocco Stanzione wrote:
> I was looking into an iptables bug on bugzilla and noticed that the way
> we're building iptables has a lot of brokenness in dapper and looks
> unnecessarily difficult to maintain.  I guess we're using Debian's
> methodology where iptables is treated as a standalone package, but it
> really likes to be compiled against the source of the running kernel, as
> it's done in Redhat and Mandriva with appropriate dependencies.  Currently
> it's built against a small chunk of (old) kernel code attached to the
> package.  The whole thing is patched with patch-o-matic, but that does
> little good since that code doesn't get into the kernel we actually use.
> Also, the netfilter code in the kernel has gone through a lot of changes
> recently.  A lot of items that were once in patch-o-matic are now in the
> mainline kernel and there's new support for a lot of very useful stuff,
> like manipulating the conntrack table from userspace.
> 
> An example of what's broken in our package is bug 16831, which is what
> started me looking into this.  The files are there, but the userspace and
> kernel code are out of sync and the rules fail.  I'd like to propose a
> relationship between the kernel package and iptables, where iptables
> depends on the kernel whose source it was built against, and where a new
> kernel build means a new iptables build.  I think this is the correct way
> to handle iptables, and I think it'll be easier to maintain than what
> we're doing now.

One of the explicit goals of our kernel packaging methodology has been to
strictly limit the number of other packages which need to be rebuilt when
the kernel changes.  This is especially important when considering that
security updates to the kernel are common in a stable release.  Currently
affected by kernel transitions in stable releases are:

- linux-source-x.y.z, the kernel itself
- linux-restricted-modules-x.y.z, modules which must be shipped separately
  due to restrictive licensing
- linux-meta, the kernel metapackages which manage transitions

Adding iptables to this list would add to the existing burden imposed by
kernel security updates.  I'd also be concerned about kernel updates causing
iptables to fail to build.

Can we find a way to keep it up to date with kernelspace while avoiding
these issues?

-- 
 - mdz