On Wed, Apr 24, 2024 at 05:20:15PM +0200, Pablo Neira Ayuso wrote: > On Wed, Apr 24, 2024 at 04:58:40PM +0200, Phil Sutter wrote: > > On Wed, Apr 24, 2024 at 04:11:59PM +0200, Alexander Kanavin wrote: > > > On 4/24/24 14:53, Phil Sutter wrote: > > > > Hi, > > > > > > > > On Wed, Apr 24, 2024 at 02:28:04PM +0200, Alexander Kanavin wrote: > > > >> From: "Maxin B. John" <maxin.john@xxxxxxxxx> > > > >> > > > >> This changes the configure behaviour from autodetecting > > > >> for libnfnetlink to having an option to disable it explicitly. > > > >> > > > >> Signed-off-by: Khem Raj <raj.khem@xxxxxxxxx> > > > >> Signed-off-by: Maxin B. John <maxin.john@xxxxxxxxx> > > > >> Signed-off-by: Alexander Kanavin <alex@xxxxxxxxxxxxx> > > > > The patch looks fine as-is, I wonder though what's the goal: Does the > > > > build system have an incompatible libnfnetlink which breaks the build? > > > > It is used by nfnl_osf only, right? So maybe introduce > > > > | AC_ARG_ENABLE([nfnl_osf], ...) > > > > instead? > > > > > > The patch is very old, and I didn't write it (I'm only cleaning up the > > > custom patches that yocto project is currently carrying). It was > > > introduced for the purposes of ensuring build determinism and > > > reproducibility: so that libnfnetlink support doesn't get quietly > > > enabled or disabled depending on what is available in the build system, > > > but can be reliably turned off or on. > > > > Thanks for the explanation. I don't quite get how a build is > > deterministic if libnfnetlink presence is not, but OK. > > IIRC, there are also dependencies on utils with libnfnetlink that > would need to be disabled too. Within iptables, we only have nfnl_osf (in utils/) which depends on it, but missing HAVE_LIBNFNETLINK effectively disables it from being built. So unless you have something else in mind, that's fine with and without this patch. Cheers, Phil