iptables and patch-o-matic

[Rocco Stanzione]

On Tuesday 10 January 2006 12:41, Matt Zimmerman wrote:
> 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?

The alternative is to keep the copy of the kernel headers used to build 
iptables current with the kernel package, and to maintain the patch-o-matic 
patches between the two packages.  Patches made to iptables without patching 
the kernel don't do any good (see bug 16831).  Trivial changes to the kernel 
won't usually require an update to the iptables copy to maintain 
compatibility, but when we're upgrading to a new kernel (as opposed to a 
bugfix release) the two should be synced up again.

The reasons you listed for not establishing a dependency link between the two 
packages make sense, and I figured that's why it was done this way.  My 
counter-argument is that the way we do it now just plain doesn't work, and 
the alternative I just described would arguably put a heavier maintenance 
burden on the packagers.  Pruning the kernel source tree down to just what 
you need is likely to be a recurring problem as the list of required files 
changes.  Patching the two trees (iptables and the kernel) separately, and 
maintaining them separately, represents duplication of effort and will 
require ongoing communication and cooperation among the maintainers.

Honestly, either solution is fine with me, but having worked in a system where 
the two packages were linked, it strikes me as the easiest and most correct 
solution.

Thanks,

Rocco