Context

I have a very basic KDE environment, just enough to be able to run Digikam. Anytime I try to delete a photo, I get an error message:

Could not start process
Unable to create io-slave: klauncher said: Unknown protocol 'trash'.

Oh, well. So I guess the FreeBSD port for Digikam fails to list a required dependency. Fixing this is a long (ongoing) journey, with lots of interesting adventures all along. This is not a step by step buid, but a series of notes about various traps I fell on the way.

KDE libraries versioning

Executive summary: you cannot build KDE libraries (such as sysutils/kfilemetadata) of a given version if it does not match exactly the installed version of kdelibs:

```plain Build log […] ===> Registering installation for kfilemetadata-4.14.3_2 as automatic pkg-static: Unable to access file /var/ports/work/usr/ports/sysutils/kfilemetadata/work/stage/usr/local/lib/libkfilemetadata.so.4.14.3: No such file or directory *** Error code 74


kfilemetadata fails to install. That file is indeed missing; the staging area
does however contain a libkfilemetadata.so.4.14.2. So why does the source package
of 4.14.3 generate a 4.14.2 library?

Answer: the library version is not set by the package itself, it comes from a
default value from:
o

```plain /usr/local/share/apps/cmake/modules/KDE4Defaults.cmake
set(GENERIC_LIB_VERSION "4.14.2")

Where does this come from?

$ pkg which /usr/local/share/apps/cmake/modules/KDE4Defaults.cmake
/usr/local/share/apps/cmake/modules/KDE4Defaults.cmake was installed by package kdelibs-4.14.2_5

Conclusion: the build dependency for kfilemetadata should list the exact same version of kdelibs, or the port won’t build.

Upgrading kdelibs

Let’s instead upgrade kdelibs from binary package, and hope for the best:

# pkg install -f kdelibs

This breaks because the binary package depends on a newer libpng, so let’s upgrade this one, keeping the old shared lib intact just in case.

$ digikam 
/usr/local/lib/libpng16.so.16: version PNG16_0 required by /usr/local/lib/libkhtml.so.5 not defined

Strange that libpng 1.6.16 does not have version 16… Sigh… OK, upgrading from png-1.6.16 to png-1.6.18 appears to fix the problem. Back on track…

Now Digikam displays its splash screen and starts initializing, then segfaults. Hell, I’ll have to bite the bullet and upgrade a few hundred packages from ports. :-(

VLC ports variants

The vlc port by defaults depends on QT5, whereas the rest of the KDE system depends on QT4. You can rebuild vlc with the QT4 option, but that’s not quite sufficient: actually phonon (part of KDE) depends explicitly on slave port vlc-qt4 (so you can’t just install vlc with QT4 option, you have to go through the separate slave port).

OpenSLP

Digikam does not segault anymore, CUPS is repaired (I had to reinstall it somewhere in the process, as it would silently fail to startup due to a missing symbol) but I still cannot delete photos. On second guess, the missing item might be kde4-runtime, not kde4-workspace.

Here the dead end is quickly reached: x11/kde4-runtime depends on net/openslp, which won’t build because of a security vulnerability… Oh well, let’s build with DISABLE_VULNERABILITIES=yes…

Epilogue

At long last, small victory: the missing piece was indeed x11/kde4-runtime. The problem has been reported. I must admit I’m getting sick and tired of the amount of breakage I need to investigate and fix most times I want to install something using the ports system. Desktop work nowadays requires humongous dependency closures that are extremely fragile, and I’m very much tempted these days to switch back to Debian for that.