The latest version of digiKam has been added to the unofficial ports tree in area51. The unofficial ports tree is where the KDE-FreeBSD team works on ports in preparation for their inclusion into the official ports tree. The trunk of that repository is basically "what's next" for the official ports tree from our point of view. There are other branches: mostly plasma5, for the upcoming (from a FreeBSD perspective, at least) KDE Frameworks 5 and Plasma 5; qt5.6 for testing the recently-released Qt 5.6. Official ports will remain Qt 5.5 for the time being.


This has been one of my bigger packaging jobs so far; also one of my first for an application I don't actually use. Here's some notes from this packaging exercise (previous digiKam version was 4.2.0 in FreeBSD, so it's quite a big jump).

  1. For dependencies within KDE -- be it frameworks, support libraries, whatever -- there's lots of links to projects.kde.org. Since projects.k.o seems to be going away in favor of other systems of organizing repositories and projects, I foresee a lot of necessary updates fixing URLs / pointers to dependencies. This is easiest to illustrate on the digiKam site, where as of right now, the dependencies-listing page links to a file in digiKam's git repository through projects.k.o, which now leads to a landing page on quickgit.k.o. From there, it's possible to find the README file in master, but nowhere near as easy as originally intended. In other words, the change in KDE infrastructure is affecting links and the availability of information to packagers already.
  2. CMakeLists that output a nice list of missing dependencies -- also the optional ones -- with good pointers to those dependencies are wonderful to work with. Keeping those pointers to dependencies up-to-date (see point 1) is extra work for application developers though.
  3. Unbundling libraries is an unexpected pain in the packager's butt, even if there's a nice pointer to find the now-unbundled libraries provided by CMakeLists. The reason it's a pain is because "update package" becomes "introduce new packages whis may not be co-installable with the old version with bundled libraries; update package".
  4. Changelogs which are written for usersare pretty much useless for packagers, since they don't include notes like (see point 3) "Libraries have been unbundled". At work-work we get things sort-of-right, writing release notes for users and including a separate section specifically for sysadmins detailing internal changes (it's a Python app, but still ..). Part of distribution outreach is making things easier for packagers by providing this kind of information in an easy-to-find and easy-to-read format.
  5. Changing CMake policies can make the simplest porting job an exercise in wading through gobs of CMake warnings. It would be nice to have a cmake command-line argument complementary to set_policy(). It means that the version of cmake relevant at the time of the software release matters -- building a six-month old release with the latest CMake can be problematic.
  6. Translations can be a bumpy ride -- appearing one release, vanishing the next. 

These are just items I jotted down based on packaging digiKam. They're not specific to digiKam, really:  for instance, I just built amor and it encounters some of these points as well.


The update to digiKam 4.14 in the unofficial ports tree is a bit weird, in the end:
  • New ports libkface and libkgeomap,
  • digiKam 4.12 is used to build the libmediawiki library,
  • digiKam 4.14 is used to build the rest of the application,
  • digiKam 4.14 is used to build all the kipi-plugins, including the mediawiki one,
  • the is (Icelandic) translation of the Google Drive plugin has gone away.
I'm actually not sure whether the mediawiki kipi-plugin is still supposed to build: it's there in the source, it builds if it's possible, but it isn't listed among the available plugins on the digiKam site nor has the digiKam team released libmediawiki standalone (like it has for libkgeomap and libkface). We've decided to keep the plugin, on the grounds that that is less change in the available packages and Fedora seems to do the same.

Anyway, this unofficial update will hopefully be followed fairly soon by an update to the official ports tree -- then the KDE-FreeBSD photography community can enjoy updated software.