libkgeomap

Pino Toscano pino at kde.org
Fri Jan 30 10:18:39 GMT 2015


On Friday 30 January 2015 09:16:47 Raymond Wooninck wrote:
> But as that 
> Digikam is moving more and more to a Qt5 application, then a Frameworks based 
> one I wonder if the maintainers will go for this separation.

I don't see how things will change because of this. Currently, the
kdegraphics libraries (libkipi, libkexiv2, libdcraw, and recently also
libkface) have regular release together with KDE SC/whatever; however,
they are bundled (as snapshots from git/master, even) in the digikam
release tarball as well, and possibly digikam even requires (it did a
couple of times in the past) functions added only to master in those
libraries, and not available in their last stable series.

In short: maintainers should simply stop bundling libraries together
with digikam, and just make sure digikam (and kipi-plugins as well)
builds and work fine at least with the latest stable series of them.

Back to the topic of this thread: I'd mildly oppose to move libkgeomap
to kdegraphics, since:
a) its API and ABI get broken from time to time (even too often), with
   no actual bump of SONAME
b) digikam people rarely care about non-master branches of those
   libraries, fixing bugs in master only and leaving stable series
   without fixes (and distros usually have to backport those on their
   own)
c) there is simply nothing that prevents something in extragear/libs
   to have own releases (and actually, that's exactly what extragear
   is for), and to be used by other applications

-- 
Pino Toscano




More information about the kde-core-devel mailing list