Page MenuHomeFreeBSD

Change the default option from mDNSResponder to avahi in kdelibs4.
ClosedPublic

Authored by rpaulo on Oct 28 2014, 8:08 PM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 6 2024, 10:35 AM
Unknown Object (File)
Oct 5 2024, 4:15 AM
Unknown Object (File)
Oct 5 2024, 2:13 AM
Unknown Object (File)
Oct 2 2024, 10:23 AM
Unknown Object (File)
Oct 2 2024, 8:32 AM
Unknown Object (File)
Sep 30 2024, 7:40 PM
Unknown Object (File)
Sep 25 2024, 11:39 PM
Unknown Object (File)
Sep 24 2024, 12:14 AM
Subscribers

Details

Reviewers
swills
rakuco
bapt
Group Reviewers
kde
Summary

Change the default option from mDNSResponder to avahi in kdelibs4.

mDNSResponder is unmaintained and was replaced by discoveryd. discoveryd is not open source yet and I don't know if it will ever be.

Test Plan

Builds fine. Need help setting up an exp-run.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

rpaulo retitled this revision from to Change the default option from mDNSResponder to avahi in kdelibs4..
rpaulo updated this object.
rpaulo edited the test plan for this revision. (Show Details)
rpaulo added reviewers: kde, bapt, swills.

Looks OK to me, from the area51 logs the farthest I can reach is r3671, where miwi wrote "More fixes, add missing net/mDNSResponder". Avahi was only introduced as an option in r4172 via bug 126494, and I guess nobody bothered to change the default.

It would be helpful to understand why you want to do this though. Is it because mDNSResponder is unmaintained? If it is, why not remove the MDNSRESPONDER option altogether?

Need help setting up an exp-run.

What kind of help do you need? Providing this patch in a bug assigned to portmgr with "exp-run" in the title and the "exp-run" flag set should be enough.

In D1021#3, @rakuco wrote:

It would be helpful to understand why you want to do this though. Is it because mDNSResponder is unmaintained? If it is, why not remove the MDNSRESPONDER option altogether?

I forgot to explain that in the description, but it's now fixed. I'd like to keep the mDNSResponder option to avoid any near term problems, but I suppose it should be removed soon.

Thanks. Someone pointed out on IRC that Avahi might not be a fully functional replacement for mDNSResponder. I have no idea about the accuracy of this information, do you? And is there something in mDNSResponder that's actively causing problems at the moment other than that it is not maintained anymore?

And let me know if you still need help with the exp-run.

In D1021#7, @rakuco wrote:

Thanks. Someone pointed out on IRC that Avahi might not be a fully functional replacement for mDNSResponder. I have no idea about the accuracy of this information, do you? And is there something in mDNSResponder that's actively causing problems at the moment other than that it is not maintained anymore?

I don't know if it's accurate or not. I'm not even sure I can test a fully functional replacement, but I'd like to see the reasons, if you have them.

And let me know if you still need help with the exp-run.

That shouldn't be a problem, thanks.

rakuco added a reviewer: rakuco.

OK. Make sure the final patch bumps PORTREVISION. An UPDATING entry would be good as well.

This revision is now accepted and ready to land.Oct 28 2014, 10:11 PM

I would like to hear the reason for this change. Currently only three ports depend on avahi-libdns (and one of them the avahi meta port), while mDNSResponder is used by 25 ports + 450 kde ports via kdelibs. This change will cause package conflicts, particularly between kde ports and cups ports.

In D1021#13, @makc wrote:

I would like to hear the reason for this change. Currently only three ports depend on avahi-libdns (and one of them the avahi meta port), while mDNSResponder is used by 25 ports + 450 kde ports via kdelibs. This change will cause package conflicts, particularly between kde ports and cups ports.

I suppose it depends on how you use mDNSResponder, but it never worked reliably with IPv6 in my case, especially with temporary addresses. mDNSResponder also uses a custom binary format for queries in its UNIX domain socket, whereas avahi it's plain text. This makes it easier to build an nss library in the base system because it doesn't depend on anything 3rd party. The other reason is explained in the description:

mDNSResponder is unmaintained and was replaced by discoveryd. discoveryd is not open source yet and I don't know if it will ever be.

It's possible that we have to change CUPS as well for all this to work.

In D1021#15, @rpaulo wrote:

I suppose it depends on how you use mDNSResponder, but it never worked reliably with IPv6 in my case, especially with temporary addresses. mDNSResponder also uses a custom binary format for queries in its UNIX domain socket, whereas avahi it's plain text. This makes it easier to build an nss library in the base system because it doesn't depend on anything 3rd party. The other reason is explained in the description:

mDNSResponder is unmaintained and was replaced by discoveryd. discoveryd is not open source yet and I don't know if it will ever be.

all right, then lets make the switch from mDNSResponder to avahi to all ports simultaneously (and perhaps deprecate the mDNSResponder port). I'd like to avoid situation when packages depend on conflicting providers.

While looking at D1031, I looked at kdelibs's dnssd/CMakeLists.txt, and it appears to choose whether to use Avahi or mDNSResponder depending on whether the avahi-common/defs.h header is found. Since we always depend on net/avahi-app, in practice we haven't built the mDNSResponder code path in a very long time (if ever), even though we depend on the port...

In D1021#17, @rakuco wrote:

While looking at D1031, I looked at kdelibs's dnssd/CMakeLists.txt, and it appears to choose whether to use Avahi or mDNSResponder depending on whether the avahi-common/defs.h header is found. Since we always depend on net/avahi-app, in practice we haven't built the mDNSResponder code path in a very long time (if ever), even though we depend on the port...

Apparently the code has significantly changed since the last time we looked at it. I suppose we simply remove ZEROCONF option from kdelibs considering its hard dependency on net/avahi-app.