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