I'm thinking ahead with you offering binary packages for Slackware. There are several packages that do not have to be installed to build the core KDE packages. I have created this list from watching the build messages and logs. There might be additional packages to add to this list: libcarddav (part of the Trinity Project, kdepim) libcaldav (part of the Trinity Project, kdepim) avahi (dns-sd, DNS service discovery/zeroconf, kdelibs/kdebase) lua hspell (Hebrew spell checking) krb5 (kerberos) OpenEXR Libraries (EXR image format support, several KDE packages) GraphicsMagick (various image filters; e.g. koffice/krita, kdebase) JRE-Java Runtime Engine (kdebindings) JDK-Java Development Kit (kdebindings) SIP PyQT3 PyKDE (Trinity KDE Python bindings; require SIP and PyQT) PostgreSQL (koffice/kexi) Transcode, ffmpeg (k3b ripping) libdvdread, libdvdnav (k3b video ripping) If the binaries are built without these packages installed, then the build process will not create any related support, even if the end-user installs those packages after installing the KDE packages. If the binaries are built with these packages installed, then the end-user should be able to make use of those hooks as soon as the additional packages are added. What happens when the packages are built to provide that support but the end-user does not have the support packages installed? I'm presuming nothing happens and the built-in support is a dead-end stub. Hopefully the xsession errors log is not filled with useless messages. I always thought the KDE developers were horribly sloppy about controlling stdout/stderr messages captured in the xsession errors log. Have you done any testing in this area or offer any observations from daily use of Trinity? As you liked the idea about two sets of packages, one embracing full third-party support and one set stripped to the essentials, seems some testing in this area will be needed if we travel that road. For my first full build set I am going to build mostly without the third-party support. I likely will install most of the third-party packages listed previously and then build another set of packages. I'm curious what the differences will be in package sizes and performance. I have both a Pentium I and II box that provide some hard-core performance testing of any distro. :) If you decide to support two sets of packages I foresee a handful of exceptions. For example, people using K3B will presume and want full ripping support out of the box. I think that package has to be built the same for either set of packages. The K3B package in Slackware never was built that way because of concerns about digital restrictions. I always thought the package should be built with full support but then just don't include the other packages with the distro. At least then when users add the necessary support packages K3B would work immediately as advertised. Darrell