The kdelibs sources were modified to avoid compile errors when the --disable-dnssd option is used and avahi is not installed.
In the stock Slackware build script that option is not used. The stock Slackware build script compiles without those errors.
In configure --help, the default option is not explicitly declared. Only the --disable-dnssd option is mentioned in the help output. There is no --enable-dnssd option mentioned in the --help options. I think the latter option is valid, however. In the stock configure there is a test for --enable-dnssd. One way or another, I presume that dnssd support is enabled by default.
To the best of my knowledge Slackware does not include any kind of dnssd service. So an obvious question is why does the Slackware build script not fail?
The stock configure file contains the following mild warning:
if test "$have_libdns_sd" = "no"; then echo "" echo "You're missing Apple mDNSResponder 85 or later, therefore" echo "dnssd will be compiled as stub, without any real functionality." echo "If you want zeroconf support (www.zeroconf.org), you should install mDNSResponder first." echo "See dnssd/INSTALL for details." echo "" all_tests=bad fi
I think this warning is the same as Trinity KDE. Yet the stock KDE 3.5.10 builds without halting if no such service is installed while the Trinity version does not.
Based upon that warning, kdelibs should compile with or without the --disable-dnssd option and the KDE DNS-SD watcher service should compile as an unfunctional stub.
That is exactly what happens when you use the --disable-dnssd flag. I am a bit confused as to why you do not want to use the flag; you are disabling a built-in Trinity feature (which I have no problem with), but why do you want the feature to be off by default? Other distributions would take the opposite approach, wanting everything turned on by default. I personally would like to keep all Trinity features enabled by default; this avoids much confusion as to why stock source builds don't support feature <X> that was advertised by the Trinity project itself.
At this point I don't think being required to use the --disable-dnssd option is the correct approach.
Related to this issue, what will happen if I compile kdelibs with avahi installed, but an end-user installs that package without avahi installed? Will KDE choke or spew forth a bunch of error messages?
Probably, but only when Zeroconf services are requested.
As we have not yet ironed out the bugs that will allow me to install these recompiled packages, I have no idea of the result. I can see the KDE DNS-SD watcher service in the my stock version of the Control Center. Hopefully compiling with avahi but installing without causes no problems and the KDE watcher services just shrugs, so to speak. I can add some verbosity in the build script explaining that building with avahi installed is a good idea but installing the kdelibs package does not require having avahi installed.
I doubt the Slackware maintainer compiled kdelibs with avahi installed. He's not that kind of person. His philosophy is to provide a basic operating system. If an end-user wants DNS-SD suppor then that would be up to the end-user. Therefore I think kdelibs should compile without needing the --disable-dns option or having avahi installed.
That is perfectly fine with me; use the --disable-dnssd flag to shut off the undesired feature as mentioned above.
I have all the original stock KDE 3.5.10 sources. Please let me know what information to forward to better resolve this issue. I can send anything from the stock Slackware build process too.
Thanks.
Darrell
I did receive this message, the one about kpersonalizer, and the one about the mouse cursors earlier.
The mouse cursor is not controlled by Trinity by default. Usually the system-wide cursor is set by a non-Trinity configuration file somewhere; unfortunately I am not familiar enough with Slackware to guess where that file resides.
You should probably file RFE bugs for the kpersonalizer stuff. Honestly I am swamped at the moment, so they will probably languish for a while unless you or someone else can provide patches.
Hope this helps some!
Tim