Bug 265328 - digikam core does not compile against RawEngine
Summary: digikam core does not compile against RawEngine
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Portability-Compilation (show other bugs)
Version: 2.0.0
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-03 20:01 UTC by Andreas K. Huettel
Modified: 2018-04-01 09:46 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
build log (778.84 KB, text/plain)
2011-02-03 20:01 UTC, Andreas K. Huettel
Details
build log (50.61 KB, text/plain)
2011-02-03 20:11 UTC, Andreas K. Huettel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas K. Huettel 2011-02-03 20:01:00 UTC
Created attachment 56832 [details]
build log

See attached build log. This is at the moment the only failure with kde-4.6.0 libraries.
Comment 1 Andreas K. Huettel 2011-02-03 20:11:18 UTC
Created attachment 56834 [details]
build log

Sorry must have clicked on wrong file
Comment 2 Michael G. Hansen 2011-02-03 20:37:11 UTC
Andreas,

yes, we depend on libkexiv2 newer than KDE 4.6, but there is no version check implemented in CMake yet. Gilles, can you add it?

Michael
Comment 3 Andreas K. Huettel 2011-02-03 20:47:22 UTC
(In reply to comment #2)
> Andreas,
> 
> yes, we depend on libkexiv2 newer than KDE 4.6, but there is no version check
> implemented in CMake yet. Gilles, can you add it?
> 
> Michael

Even better would be of course if the version check (could optionally) just disables the critical feature... otherwise we're back at the bundling point again...
Comment 4 S. Burmeister 2011-02-08 13:20:27 UTC
Does digikam without linkexiv2 make any sense or what else but to disable the use of libkexiv2 would you suggesT?
Comment 5 Andreas K. Huettel 2011-02-08 13:39:01 UTC
Careful, things are getting mixed up here. 

* digikam-2 works perfectly fine with _libkexiv2_ from kde-4.6.0

* digikam-2 fails to build with _libkdcraw_ from kde-4.6.0

libkdcraw is the only problem, all other libraries from kde-4.6.0 seem to be sufficient.


(In reply to comment #4)
> Does digikam without linkexiv2 make any sense or what else but to disable the
> use of libkexiv2 would you suggesT?
Comment 6 S. Burmeister 2011-02-08 13:54:57 UTC
Are they?

No matter whether it is true for this special case or not, what do you suggest in case current digikam would not work with libkexiv2 from KDE 4.6 but only the bundled libkexiv2?

AFAIK there are two possibilities for that scenario:

1. Digikam uses its bundled libkexiv2
2. Digikam fails to build because it must not use any bundled libs.

Hence I ask, what features you suggest to disable if only the bundled libkexiv2 works fully with digikam.
Comment 7 Andreas K. Huettel 2011-02-08 17:01:39 UTC
S. Burmeister, 

Given the QA policies of Gentoo Linux, bundled inofficial versions of KDE libraries will not be used in any package in the main tree or even the KDE overlay, the same as bundled copies of any other library. There have already been many discussions about it, but the decision from our side has been made. I doubt that other distributions will react otherwise, but that is their decision.

Please at least try to appreciate that I am wasting my time here trying to get this code includeable.
Comment 8 S. Burmeister 2011-02-08 17:21:38 UTC
Sure, I just wanted to know how you thought it would be possible to get around the dependency on the bundled libs by disabling features. In fact the latter might work for some but not exiv2 or something similar crucial.

openSUSE already ships the bundled libs in their repos for digikam > 1.7 or whatever the version was that needed at least KDE 4.5. So other distributions do react otherwise than Gentoo.

No problem with Gentoo taking that decision – just assuming that everybody else has the same view is false.
Comment 9 Michael G. Hansen 2011-02-21 21:49:36 UTC
Git commit 1be2df36983ff867e34b38a5af903758e1cac337 by Michael Georg Hansen.
Committed on 21/02/2011 at 21:47.
Pushed by mghansen into branch 'development/2.0'.

Report the version of libkdcraw which was found. Later, a check for the required version can be added. However, for libkdcraw to report its version number, you need the development version, but at least it's a start.

CCBUG: 265328

M  +8    -0    CMakeLists.txt     

http://commits.kde.org/digikam/1be2df36983ff867e34b38a5af903758e1cac337
Comment 10 Kevin Kofler 2011-02-25 23:47:42 UTC
Fedora will not ship Digikam with bundled libs either. At most, we can backport updated libs to our kdegraphics package if needed, but we'd rather not have to do that. But we will ship only one copy of the libraries. If we upgrade them, we have to upgrade them for everyone, not just Digikam.
Comment 11 Andreas K. Huettel 2011-03-04 12:29:13 UTC
https://qa.mandriva.com/show_bug.cgi?id=62692

"Angelo Naselli 2011-03-04 11:51:30 CET
Philippe as far as i can say,
digikam 2.0.0 can't be installed on the system without breaking
compatibility with official kdegraphics.
So it won't be added in mandriva 2011.0 at least that is what I understood 
kde-team decided.
Certainly if things change it will be added.
Sorry"
Comment 12 S. Burmeister 2011-03-04 19:55:48 UTC
(In reply to comment #11)
> https://qa.mandriva.com/show_bug.cgi?id=62692
> 
> "Angelo Naselli 2011-03-04 11:51:30 CET
> Philippe as far as i can say,
> digikam 2.0.0 can't be installed on the system without breaking
> compatibility with official kdegraphics.
> So it won't be added in mandriva 2011.0 at least that is what I understood 
> kde-team decided.
> Certainly if things change it will be added.
> Sorry"

And at the end of the bug report:

"just to confirm that Mandriva KDE Team will backport this during 2011 release
cycle but won't release digikam 2.0 for 2011.0"
Comment 13 caulier.gilles 2011-11-03 12:17:02 UTC
This file can be closed now ?

Gilles Caulier
Comment 14 caulier.gilles 2011-12-13 13:13:55 UTC
Andreas,

This file still valid ?

Gilles Caulier
Comment 15 Andreas K. Huettel 2013-02-04 12:14:17 UTC
This is obsolete now...