> 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