[Dnsmasq-discuss] Enable HAVE_IPSET by default

Simon Kelley simon at thekelleys.org.uk
Thu Mar 21 10:08:02 GMT 2013


On 20/03/13 17:31, Jason A. Donenfeld wrote:
> Hi Simon,
>
> It's just occurred to me that no router developer is going to know to
> turn HAVE_IPSET on, and hence, it won't be available immediately on any
> devices, which is a bummer. Further, unless the --ipset= options are
> used, HAVE_IPSET doesn't contribute at _all_ to the runtime of the app.
> And even further, if HAVE_LINUX_NETWORK isn't enabled, HAVE_IPSET is
> automatically disabled.
>
> Makes sense, then, I think, to uncomment HAVE_IPSET by default.
>
> How about it?
>

I'm torn.

The main reason for not including this is to reduce footprint. (It does 
affect binary size, which matters, but the delta isn't going to be very 
big.)

The second reason (in general) for excluding stuff at compile time is to 
maintain the invariant that the distributed tarball can be built with 
just a C-compiler and make: no other library or tool dependencies. This 
was relevant for the first versions of ipset, but is no longer a factor 
as it doesn't depend on external libraries.

OTOH.....

Router firmware makers, in my experience, make definite decisions about 
what they want included at compile time: the defaults as I distribute 
them are not very relevant, as they get overridden. Ideally, you want 
router distros to actively take up the new facility and support it in 
their configuration system/ web pages/ documentation.

"Full fat" distro packagers also pick what they want, taking into 
account that library dependencies are not a problem. I include ipset in 
the Debian dnsmasq package, that will cascade to Ubuntu. I'd expect 
Fedora and thus Redhat to take the same path.


Finally, if it's going to be on by default, and given the limited size 
delta/lack of library definitions, there's an argument for not making it 
compile-time selectable at all. Every compile-time switch contributes to 
the combinatorial explosion of possible binaries, and lots of bugs come 
from unanticipated interactions in untested compile-flag combinations.


Opinions, anyone?



Simon.









More information about the Dnsmasq-discuss mailing list