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.