Version: 1.3.0 (using KDE 4.4.4) OS: Linux Digikam 1.3.0 cannot be compiled with KDE 4.4.4, which is the latest release. It needs to be marked as a developmental release until KDE releases the libkexiv2 and libkdcraw libraries that are new enough for it to compile. Reproducible: Didn't try Steps to Reproduce: Download and try to compile DigiKam 1.3.0 Actual Results: Fails on detection of libraries. Expected Results: Clean compile.
*** Bug 242387 has been marked as a duplicate of this bug. ***
And then ? Compile yourself libkdcraw and libkexiv2 from trunk. We (digiKam team) manage this code from kdegraphics. We can said that it can be used in production as well... Gilles Caulier
Hmm Gilles I also think it was a bad move to put libkipi into kdegraphics. We can't tell users to compile something against unreleased libraries. A lot of packagers / distributions will not update digiKam because of this. We develop libkipi and such, so we are responsible for releasing it. If we give it into the hands of KDE, we need to add digiKam into the official KDE packages, too (which would mean we have a 6 month release cycle). Or at least make digiKam compile with older versions of the libs. The way it is right now doesn't work... If you're downloading Firefox for example, you also don't need to compile some libs from trunk, if you would have to, FF would be off the surface again and Chrome or Opera would be the leading "free" Browser.
(In reply to comment #3) > Hmm Gilles I also think it was a bad move to put libkipi into kdegraphics. And libkexiv2 and libkdcraw...
And what if we add yet another feature in digiKam that will need a newer version of the libs now? KDE 4.x will be released, and digiKam will again fail to compile. This simply doesn't work.
I do some software testing for Sorcerer Linux. In Sorcerer, at least, we will keep DigiKam at version 1.2.0 until KDE releases the newer version of the libraries that DigiKam 1.3.0 needs to compile. It's unfortunate that DigiKam had tied itself to the KDE release cycle. I enjoy using the program, and there is nothing else out there that even comes close in funtionality. I will just have to wait a while longer to play with the latest functions. Thanks for looking into this, though.
libkipi need to be in kdegraphics because Gwenview implements Kipi, and is part of kdegraphics. We are http://www.kde.org/stuff/swlabels/part_of_the_kde_family_horizontal_190.png We have for a good long time preserved compatibility with older libkdcraw releases, but at some point I think it's ok to make a cut.
It doesn't help that with libkexiv2 and libkdcraw in KDE release cycles, their version numbers are now invisible to users - if distributions ship a combined "kdegraphics" release then it's version number will be 4.4.4 (doesn't work) or 4.5.0 (would do). Even distributions that split kdegraphics down into it's sections so that only the needed parts are installed keep the same number as the tarball the package is built from - so my Gentoo system has kde-base/libkexiv2 version 4.4.4 installed (i.e. the version from KDE release 4.4.4), yet when I try to build digikam I get an error about libkexiv2 >= 1.1.0 - doesn't make a lot of sense until I go digging in some depth. Would it not at least make sense to use the KDE-wide version numbers for libkexiv2 if it is only to be released as part of KDE-wide release tarballs? Or if we are to consider these libraries to be only used by digikam and kipi-plugins (not really true, I've found thumbnailers and plasma add-ons using libkexiv2), could there be some instructions on how to static link them to these libraries? I've tried to point CMake at the compiled but uninstalled libraries from kdegraphics, but to no avail (it still can't see them).
Libkexiv2 and libkdcraw version are not invisible. Go to Help/Components info menu entry from digiKam... All is there... Look like Mandriva package very easily these both libraries with KDE 4.4.x : ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/2010.1/i586/media/main/release/digikam-1.3.0-1mdv2010.1.i586.rpm ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/2010.1/i586/media/main/release/libkexiv2_8-4.4.3-3mdv2010.1.i586.rpm ftp://ftp.proxad.net/pub/Distributions_Linux/MandrivaLinux/official/2010.1/i586/media/main/release/libkdcraw8-4.4.3-3mdv2010.1.i586.rpm Why not other distro cannot do it ? As i already said previously, these libraries are maintained by digiKam team. We are very well placed to said if these libraries can be used in production or not, as well... I know and i understand that way to release these librairies are not common, but we (digiKam team) cannot synchronize digiKam release with KDE release, which is toyo long. This is not a critic, it's just my viewpoint. The reason to host these libraries in kdegraphics is to not to need to package it by us. Time is limited and we prefer to develop/hack/fix/improve. Gilles Caulier
As long as the libraries are included in the KDEgraphics libs, that is what most of the world will use, and what will most probably be seen as stable. Now I certainly would not like to get in your way developing software. All I would like to see is that development releases be labeled as such until the libraries they depend upon are released. Normally, one would expect to do a little more jumping through hoops to pull a development version of whatever software, and might have to get updated libraries they depend upon. Stable stuff should just build out of the box with the latest released libraries. Imagine if all software required you to go find some git or svn repository and download libraries only after you have tried to compile the "stable" version? You would become frustrated, no? With more than 4000 different pieces of software making up even a tiny distrobution, imagine going to get development libraries for every bit of software you package... it becomes a nightmare. Kind regards, -Evert Vorster-