3.2 KiB
| layout | title | date | comments | categories |
|---|---|---|---|---|
| post | Digikam, dependencies, and building KDE libraries | 2015-09-05 12:49:51 +0200 | true |
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.
Building KDE workspace
A little grep'ping in port plists hints that the missing dep might be x11/kde4-workspace. Alright, let's build that.
[...]
===> 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
The 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
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.
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
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...
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. :-(