Epilogue to latest Digikam woes

source/_posts/2015-09-05-building-kde-libraries.markdown

@@ -18,13 +18,17 @@ 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.
+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.
 
-Building KDE workspace
+KDE libraries versioning
-======================
+========================
 
-A little grep'ping in port plists hints that the missing dep
+Executive summary: you cannot build KDE libraries (such
-might be x11/kde4-workspace. Alright, let's build that.
+as sysutils/kfilemetadata) of a given version if it does
+not match exactly the installed version of kdelibs:
 
 ```plain Build log
 [...]
@@ -33,13 +37,10 @@ pkg-static: Unable to access file /var/ports/work/usr/ports/sysutils/kfilemetada
 *** Error code 74
 ```
 
-The kfilemetadata fails to install. That file is indeed missing; the staging area
+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?
 
-A trip in KDE-build-land
-========================
-
 Answer: the library version is not set by the package itself, it comes from a
 default value from:
 o
@@ -58,14 +59,6 @@ $ pkg which /usr/local/share/apps/cmake/modules/KDE4Defaults.cmake
 Conclusion: the build dependency for kfilemetadata should list the exact same version of
 kdelibs, or the port won't build.
 
-So, we now need to upgrade kdelibs in order to be able to build kfilemetadata, which
-is a dependency of kde4-workspace, which is an unlisted dependency of Digikam.
-
-Rebuilding kdelibs from sources involves a portmaster operation that will on this
-system rebuild a few hundred depedencies, so doesn't sound like an attractive option
-(too big a build to babysit, with likely hiccups on the way, and in any case too
-much of an earthquake with so many ports being updated at once.
-
 Upgrading kdelibs
 =================
 
@@ -86,26 +79,38 @@ $ digikam
 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...
 
-Back to KDE Workspace
-=====================
-
-Side note: hey, couldn't I just install kde-workspace from packages as well? Well,
-for some reason pkg wants to remove my TeXlive install, and upgrade two dozen other
-packages, so thanks, but no thanks. (I would have gone for it were it not for the
-removal of TeXlive. But that's too much breakage to fix downstream.)
-
 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. :-(
 
-portupgrade: Be Afraid, Be Very Afraid
-======================================
 
-```plain
+VLC ports variants
-# portmaster -dvw digikam
+==================
-```
+
+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`...
 
-(It's beyond my understanding why `-w`, i.e. "Keep old shared libs in the hope of not rendering
+Epilogue
-other applications unusable" is not the default)
+========
 
-As a corollary, I'll have to upgrade to GnuPG 2.1 (dependncy of `security/gpgme`) -- I had so
+At long last, small victory: the missing piece was indeed x11/kde4-runtime.
-far carefully stuck with `security/gnupg20`.
+The problem has been `reportd <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203222>`.
+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.