# netatalk3: Why does it need Cairo (and X11)?



## ultrakomm (Jul 22, 2013)

Hi!

I'm trying to build Netatalk3 on my NAS. It works fine, but it for some reason builds Cairo and X11. Why does it do this? I don't really need them for sharing files to my Mac clients. Can I disable it or prevent it from doing so somehow?

Thanks,
ultra


----------



## adripillo (Jul 22, 2013)

ultrakomm said:
			
		

> Hi!
> 
> I'm trying to build netatalk3 on my NAS. It works fine, but it for some reason builds Cairo and X11. Why does it do this? I don't really need them for sharing files to my Mac clients. Can I disable it or prevent it from doing so somehow?
> 
> ...



I do not know if this going to work but you can try to build it again from ports but doing first:


```
# make config
```

And see if it allows you to uncheck it from the configuration.


----------



## adripillo (Jul 22, 2013)

Also you can add WITHOUT_X11 in /etc/make.conf


----------



## SirDice (Jul 23, 2013)

I'm guessing it's net/avahi-app that pulls those in.


----------



## kpa (Jul 23, 2013)

Yes, one of my pet peeves is that net/avahi-app is written by idiots and pulls in all sorts of dependencies that can not be easily detached from it because under Linux where it comes from it is assumed that X11 is part of the OS and the dependencies are not seen as heavy.

Unfortunately there's no other way to have IPv6 capable mDNS in FreeBSD than install net/avahi-app.


----------



## SirDice (Jul 23, 2013)

You may be able to circumvent it by building net/avahi first with WITHOUT_X11 set. The avahi-app port contains a GUI Avahi browser, not really sure why a network filesystem has to depend on a GUI application. I can understand the need for libraries and such.


----------



## Anonymous (Jul 23, 2013)

kpa said:
			
		

> ... Unfortunately there's no other way to have IPv6 capable mDNS in FreeBSD than install net/avahi-app.



Are you sure? Did you try the original net/mDNSResponder from Apple? According to the documentation from Apple, it could have IPv6 addresses as well as IPv4 addresses in its DNS records.

I have running mDNSResponder for service advertisement on IPv4 addresses only, so I cannot confirm that it works for IPv6, however, for the time being I cannot see any reason why not.


----------



## kpa (Jul 23, 2013)

rolfheinrich said:
			
		

> Are you sure? Did you try the original net/mDNSResponder from Apple? According to the documentation from Apple, it could have IPv6 addresses as well as IPv4 addresses in its DNS records.
> 
> I have running mDNSResponder for service advertisement on IPv4 addresses only, so I cannot confirm that it works for IPv6, however, for the time being I cannot see any reason why not.



No, the FreeBSD port does not do IPv6. I have tried it on numerous occasions. Only the Apple implementation of mDNSResponder in OS X does IPv6 at the moment.


----------



## Anonymous (Jul 23, 2013)

kpa said:
			
		

> No, the FreeBSD port does not do IPv6. I have tried it on numerous occasions. Only the Apple implementation of mDNSResponder in OS X does IPv6 at the moment.



Consider installing the latest mDNSResponder-379.37. For me this worked by creating a locally modified port:

`$ cp -R mDNSResponder ~/modports/mDNSResponder379`
`$ cd ~/modports/mDNSResponder379`

Then patch the copied port using the attached patch file for adapting it to the new distribution from Apple:
`$ patch -p1 < mDNSResponder379.patch`
`$ sudo make install clean`

This version opens IPv4 and IPv6 sockets and advertises IPv4 and IPv6 addresses.


----------



## Anonymous (Jul 24, 2013)

*After Math (mDNSResponder update)*



			
				rolfheinrich said:
			
		

> Consider installing the latest mDNSResponder-379.37. For me this worked by creating a locally modified port ... This version opens IPv4 and IPv6 sockets and advertises IPv4 and IPv6 addresses.



After elaborating the mDNSResponder379.patch and after writing the above post, I saw that on May, 9th 2013 there was already submitted the PR 178448. Apparently a patch for the updating the current port 333.10 to 379.37 was attached to the PR, but it has been removed for some reason. Anyway, the maintainer seems to not have responded to the update request for more than two months. I guess this qualifies for opening a maintainer timeout case.


----------

