Bug 213898
| Summary: | net/mDNSResponder unconditionally enables IPV6 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Mikhail Teterin <mi> | ||||
| Component: | Individual Port(s) | Assignee: | Po-Chuan Hsieh <sunpoet> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | Flags: | bugzilla:
maintainer-feedback?
(sunpoet) |
||||
| Priority: | --- | ||||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
I understand what you mean but this patch is incorrect. We do not have WITHOUT variable. I'll make a new one. (In reply to Sunpoet Po-Chuan Hsieh from comment #1) > We do not have WITHOUT variable. A number of ports have the IPV6-option (www/lynx is one example). I set it (and some others) system-wide in /etc/make.conf: WITHOUT=DOCS IPV6 DEBUG KERBEROS GCRYPT INTEGER_SAMPLES this helps me avoid the options-dialog in some ports completely. I suppose, this particular option's default setting can depend on whether or not the base's WITHOUT_INET6 is set (to "yes"). That is, if you choose to make this port interactive by explicitly adding the IPV6-option to it. The patch will remain the same, though :-) A commit references this bug: Author: sunpoet Date: Sat Nov 19 08:03:00 UTC 2016 New revision: 426352 URL: https://svnweb.freebsd.org/changeset/ports/426352 Log: - Add IPV6 option PR: 213898 Reported by: mi Changes: head/net/mDNSResponder/Makefile |
Created attachment 176292 [details] Turn off HAVE_IPV6, if WITHOUT contains "IPV6" The port goes through some effort to enable IPV6 functionality. Unfortunately, it does so unconditionally -- even where the OS and the kernel are built without it. On such systems the resulting daemons refuse to even start: % /usr/local/bin/mDNSResponderPosix .... socket AF_INET6: Address family not supported by protocol family The enclosed patch examines the local machine's WITHOUT-setting and turns off the HAVE_IPV6 flag, if IPV6 is disabled. Rebuilt thus, the daemon can start on my machines here. The proper fix would've been for the upstream to stop treating the run-time absence of AF_INET6-support as fatal. But that may be too much for the port to fix...