), so whatever i suggest may not even be applicable to Salix at all. In case you're interested, i can give some ideas of how & why i built avahi for zenwalk the way i did. But by all means feel free to do as you please
One thing: zeroconf, avahi, bonjour, mDNS, the same protocol has a confusingly large number of names. Apple itself is guiolty of the names zeroconf, bonjour and mDNS. Avahi is one of the implementations of this 'zeroconf' protocol. There have been others. For some of these, avahi has the facility to provide the same interface as the 'other' implementation. So: For ease of integration, i'd recommend enabling the build of the mDNS (alias original Apple) compatibility interface: some applications will want to link into avahi pretending to 'see' the original Apple interface. There is another 'incarnation' of the 'zeroconf' protocol, called howl. I saw no reason to disablling the compatibility mode for it. If any application 'wants' to interface using C/C++ with avahi, i prefer to have the compatibility headers/libraries present
. In my buildfile, i configured the user/group 'deamon', but feel free to do as you please
I disabled autopid, and provide libdaemon, but i have no good reason for that. Possibly, there *is* a good reason, but i 'took over' building avahi from the zenwalk maintainer 'Tibors', who selected that, and i've never seen a good reason to change it.As for 'language interfaces'/'bindings', i've been a bit more conservative. I did enable 'gtk' (assuming Salix is also a gtk-ish distro, that seems logical), but also did not disable python and enabled pygtk. The reason is that -if all goes well- this results in that -as part of an avahi build- a number of gui-applications are compiled: a standalone gui-avahi-browser, a ssh and a vnc browser. These gui-apps allow you to see what computers and what services are present on the local network. You can also browse ssh and vnc servers, and -if all is well- connect to them from the gui app. Avahi itself tends to be very low-profile, so having *some* apps in the menu as a result of avahi being present is -in my view- not bad. Expect one problem: there is no 'icon' for the menu items in the avahi source package. I 'stole' one from the avahi www-site.
I am one of the zenwalk-kde-nutcases, so to find *me* enabling Qt4 should not be a surprise.
kde4/qt4 hase 'native' support for avahi, and i always enjoy entering the 'zeroconf:/' url in my konqueror to get a view of ssh, sftp and the like services as avalable. NB: it is not difficult to make kde support more protocols, that is just very badly documented....W.r.t. kde3/Qt3, well that *is* a bit of a troublesome thing: there is kdnssd-avahi, but packaging that results in a number of files that are supposed to over-write some of the libraries of the kde3-libs package. Oogly to the extreme: the order of installing packages becomes important: over-write kdnssd-avahi with a 'fresh' kdelibs package, and you lose the kdnssd-avahi. I solved that by building kdnssd-avahi *into* the kde3libs package itself (i was also the kde3-maintainer, so i could get away with that..). I called that the 'avahi-dance' with kdelibs: over-write the kdelibs file, before the actual packaging, and the resulting kdelibs-with-kdnssd-avahi-inside package is one package, that avoids the 'install-order problem. Still not very 'clean' but that is at least robust. Unless you are interested in the more obscure tricks of package-building, i'd not recommend you follow that lead
Besides, the days of kde3 are more than numbered, even i run kde4 full-time now And *after* you've built a nice avahi-package comes the 2-nd hurdle: to see how many other packages/packagers will actually build in support for avahi (or zeroconf by any of its other names). Because: having a 'bare' avahi is about half the trick: if no program exports its services to avahi, and if nobody actually acesses those services *using* avahi, then building avahi itself is more or less an excercise in futility. What is possible:
- kde (3 and 4, both have support)
- kdegames: kbatteship group play
- pidgin (bonjour chat)
- cups (i managed to get that active once, but i have no operational printer....
)- apache (browse for www-servers...)
- amarok (experimented with mt-daapd: an i-tunes server on your local machine.. almost works...)
- ssh/sftp (browse and up/download... )
- vnc
Some applications do not have a 'native' support for avahi/zeroconf: they have no source that 'presents' services for avahi to pass along. But: avahi has a 'cheat-mode', which can be used to export the existence of the services. If you'd care to look at the tail of my zenwalk buildfile, you'd find some scripting that sets files so that some services that are enabled in the rc-scripts are 'fake-registered' with avahi. A bit tricky , and not completely 'clean', but better than nothing...
So, thus i've been ranting long enough..... Good building...
*troll mode off*
