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:
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:
1 2 3 4
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
Where does this come from?
Conclusion: the build dependency for kfilemetadata should list the exact same version of kdelibs, or the port won’t build.
Let’s instead upgrade kdelibs from binary package, and hope for the best:
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.
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).
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
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.