labnotes/_source/_posts/2015-09-05-building-kde-libraries.markdown

---
layout: post
title: "Digikam, dependencies, and building KDE libraries"
date: 2015-09-05 12:49:51 +0200
comments: true
categories: 
---

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:

```plain
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?

```plain
$ 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:

```plain
# 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.

```plain
$ 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](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.