You can add the kde-forge repo to your fedora, it contains always the latest KDE packages for the current fedora distro (so now it's 13) and also for the previous release. So you can add this, update to KDE 4.5.1 and happily compile digiKam 1.4.0 or even 2.0 for that matter. This repo is maintained by fedora people, so you don't have to worry about the quality and compatibility of the packages. I'm using it myself and I'm compiling digiKam on it everyday ;) 

Anyway, here it is: http://kde-redhat.sourceforge.net/

Some KDE apps (namely Gwenview, Krita) depend on those libraries, so they are not going to be removed from kdegraphics.
We will also not put chains around our feet and stop developing just because some downstream doesnt care to package dependencies

and now, Plasma components use libkexiv2 to play with image metadata, as slideshow and desktop background...

Gilles Caulier

(In reply to comment #1)
> You can add the kde-forge repo to your fedora, it contains always the latest
> KDE packages for the current fedora distro (so now it's 13) and also for the
> previous release. So you can add this, update to KDE 4.5.1 and happily compile
> digiKam 1.4.0 or even 2.0 for that matter. This repo is maintained by fedora
> people, so you don't have to worry about the quality and compatibility of the
> packages. I'm using it myself and I'm compiling digiKam on it everyday ;) 
> 
> Anyway, here it is: http://kde-redhat.sourceforge.net/

This is a good reply - useful link and an insight into what KDE updates will eventually arrive in the standard repos, many thanks Martin

(In reply to comment #3)
> and now, Plasma components use libkexiv2 to play with image metadata, as
> slideshow and desktop background...
> 
> Gilles Caulier

1) Kaffeine (1.1) and k3b (2.1.0) are both independent of the KDE4 version - Digikam (1.4.0) and Kipiplugins (1.4.0) should be too...

2) How should kdegraphics be packaged so that the libkdcraw and libkexiv2 can be upgraded using yum (or any package manager come to that) whilst still keeping a stable version of the KDE desktop installed?

3) Please keep developing Digikam and Kipiplugins!

> 1) Kaffeine (1.1) and k3b (2.1.0) are both independent of the KDE4 version -
> Digikam (1.4.0) and Kipiplugins (1.4.0) should be too...

IIRC the main driving force was Gwenview when it became the default KDE picture viewer

> 
> 2) How should kdegraphics be packaged so that the libkdcraw and libkexiv2 can
> be upgraded using yum (or any package manager come to that) whilst still
> keeping a stable version of the KDE desktop installed?

dir /usr/lib64/libkdcraw.so*
/usr/lib64/libkdcraw.so -> libkdcraw.so.9
/usr/lib64/libkdcraw.so.8 -> libkdcraw.so.8.1.0
/usr/lib64/libkdcraw.so.8.1.0
/usr/lib64/libkdcraw.so.9 -> libkdcraw.so.9.0.0
/usr/lib64/libkdcraw.so.9.0.0

zypper search kdcraw
i | libkdcraw8           | Shared library interface around dcraw    | Paket

We increase the binary version number with each binary incompatible release.
There's no problem to install them in parallel. The 8 is from KDE 4.5 OpenSuse packages, 9 is probably my self-installed version.
As you see, opensuse even includes the "8" in the package name.

> 3) Please keep developing Digikam and Kipiplugins!

For sure ;-)

I re-open this file due to change in digiKam 2.0.0 which is now a collection of code including kipi-plugins and all kdegraphics/libs (devel version, increased than kdegraphics/libs)

In fact kdegraphics/libs still avaialble, but digiKam will be published now with all kdegraphics/libs require to run digiKam and kipi-plugins.

Gilles Caulier

(In reply to comment #7)
> I re-open this file due to change in digiKam 2.0.0 which is now a collection of
> code including kipi-plugins and all kdegraphics/libs (devel version, increased
> than kdegraphics/libs)
> 
> In fact kdegraphics/libs still avaialble, but digiKam will be published now
> with all kdegraphics/libs require to run digiKam and kipi-plugins.
> 
Hello Gilles,
I must strongly object to this idea.
You introduce possible security threat and possibility to introduce bugs just thanks to the code duplication you are right now doing. For more i really recommend fedora guys description and reasoning why the bundling is bad <http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries>.

I know you probably think you are making things easier for us maintainers but contrary you are just making sure that we wont probably ship the named versions of digikam at all. Given the fact we will allow only official libraries to be linked we wil have to wait onto the official libs to be released and then use those if possible. Anything that uses bundled libraries at this scale wont be able to get to Gentoo main tree at all (also i am quite sure at least debian and redhat guys will do the same).

So how should one approach issues with libraries like this:
1) use only older code and rely on that - not quite bright
2) conditionaly enable more features when linking to some version - really smart

So given we choose the second option we will be able to ship digikam with "older" libraries where you can develop shiny new features (most applications still support kde 4.4 and just few have beta releases that start to require 4.5). If we as packages find that libraries were updated (given soname change or whatever else [user updated his kde]) it will trigger update of the digikam itself, so it enables more features that will be availible at hand for the user.

Tiny example of what i mean by second possible option (sorry for python, but i aint exacly c expert but it is just proof of concept anyway)

import sys
if sys.hexversion < 0x02070000:
    # do complex calculation with some features
else:
    # user gave us shiny new python so we can use full features YAY

I really hope we will convince you guys to change your decision because i really dont want to remove digikam from main tree since I am its user too. :)

With best
Gentoo KDE Team Lead
Gentoo QA Member

I think the decision of Gilles to include dependencies in the distribution of DigiKam is not to help linux packagers butto help any user who wants to test and provide debug information about the latest version of DigiKam using Linux, Windows or MacOSX.
If I understood well, the way the bundle is done using CMake scripts does not prevent packager from doing things properly and building packages which reference the libraries of the distribution. If the sufficient dependencies are found then the libraries which are bundled with DigiKam will not be used during compilation (Gilles Marcel correct me if I am wrong).

The point 1.2 1.3 1.4 1.5 <http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries> do not apply to these libraries, because they are not a fork but are developed by the DigiKam team.

Moreover, in the exception you can read:
"When an application needs unreleased features of a library and that library has committed to those features (usually, the changes are checked into the trunk branch of the upstream's revision control system) but the library has not yet made a release that has that code an exception may be granted to bundle that library until the Fedora packages contain the necessary extra features."

I think this is a good description of the situation for the DigiKam librairies.

Julien

(In reply to comment #8)

Reading the recent comments it appears that the main issue has not been understood, namely the libs that Digikam/Kipi-plugins require are bundled with Kmultimedialibs. 

Thus, depending on the distribution and release you are using, you cannot use any of the current Digikam releases.

For example:

Fedora 12 (KDE 4.4.x) users are stuck with Digikam <= 1.2.0

Fedora 13 & 14 (KDE 4.5.x) - Digikam <= 1.7.0

(the forthcoming) Fedora 15 (KDE 4.6.x) - Digikam 2.0.0?

This is of course nonsense. Whilst some of the KDE applications are dependant on libraries developed by the Digikam team, the libs should be packaged separately and not bundled with Kmultimedialibs as now.

I think the very fact that I can use digikam 2 and 1.8 with KDE 4.5 on openSUSE 11.3 proves you wrong.

So rather than blaming digikam blame whoever does packaging for your distro.

(In reply to comment #11)
> I think the very fact that I can use digikam 2 and 1.8 with KDE 4.5 on openSUSE
> 11.3 proves you wrong.
> 
> So rather than blaming digikam blame whoever does packaging for your distro.

Sorry S. but I think you have an attitude problem - there is not a hint of blaming anyone in my comment.

When you look at the following listing you will see that the Fedora packagers have packed the KDESC as predetermined by KDE:

kdeaccessibility.x86_64                1:4.5.5-1.fc14              @anaconda-InstallationRepo-201010211827.x86_64
kdeartwork.x86_64                      4.5.5-1.fc14                @anaconda-InstallationRepo-201010211827.x86_64
kdebase.x86_64                         6:4.5.5-1.fc14              @anaconda-InstallationRepo-201010211827.x86_64
kdebase-runtime.x86_64                 4.5.5-1.fc14                @anaconda-InstallationRepo-201010211827.x86_64
kdebase-workspace.x86_64               4.5.5-2.fc14                @anaconda-InstallationRepo-201010211827.x86_64
kdeedu.x86_64                          4.5.5-1.fc14                @anaconda-InstallationRepo-201010211827.x86_64
kdegames.x86_64                        6:4.5.5-1.fc14              @anaconda-InstallationRepo-201010211827.x86_64
kdegraphics.x86_64                     7:4.5.5-1.fc14              @anaconda-InstallationRepo-201010211827.x86_64
kdelibs.x86_64                         6:4.5.5-1.fc14              @anaconda-InstallationRepo-201010211827.x86_64
kdelibs-common.x86_64                  6:4.5.5-1.fc14              @anaconda-InstallationRepo-201010211827.x86_64
kdemultimedia.x86_64                   6:4.5.5-1.fc14              @anaconda-InstallationRepo-201010211827.x86_64
kdenetwork.x86_64                      7:4.5.5-1.fc14              @anaconda-InstallationRepo-201010211827.x86_64
kdepim.x86_64                          6:4.4.9-2.fc14              @anaconda-InstallationRepo-201010211827.x86_64
kdepimlibs.x86_64                      4.5.5-1.fc14                @anaconda-InstallationRepo-201010211827.x86_64
kdeplasma-addons.x86_64                4.5.5-1.fc14                @anaconda-InstallationRepo-201010211827.x86_64
kdesdk.x86_64                          4.5.5-1.fc14                @anaconda-InstallationRepo-201010211827.x86_64
kdeutils.x86_64                        6:4.5.5-1.fc14              @anaconda-InstallationRepo-201010211827.x86_64
kdeadmin.x86_64                        7:4.5.5-1.fc14              updates      
kdebindings.x86_64                     4.5.5-1.fc14                updates      
kdegraphics-devel.x86_64               7:4.5.5-1.fc14              updates      
kdetoys.x86_64                         7:4.5.5-1.fc14              updates

(In reply to comment #12)
> Sorry S. but I think you have an attitude problem - there is not a hint of
> blaming anyone in my comment.

If you say so!

> When you look at the following listing you will see that the Fedora packagers
> have packed the KDESC as predetermined by KDE:

You do not get the point! If Fedora is not able to package digikam in a way that makes it accessible to their users that's entirely their problem and not a bug in digikam! Hence re-opening this bug is useless.

If you would have read my comment and the other comments in this report you would have gathered that your claim is wrong and thus your arguments regarding "cannot use" refuted.

Please submit a bug at fedora's bugzilla about their packaging and refer to openSUSE if they need help on how to package digikam 1.8 or 2.0 in a way that it can be used with KDE 4.5 or other versions.

Please guys this bug is not about what distribution package what KDE version in their main repository.
Simple fact even tho Digikam maintainers are also maintainers of the named libraries they now try to bundle should make them rather split them off the kdegraphics module and make them external libraries so both KDE core stuff and digikam can depend on them without relying on the whole release cycle for KDE SC.

Still my comment about how to manage mutliple versions of libraries apply, yet with keeping abi compatibility it is not really that hard task.

The note about unreleased libraries here does not apply, because you say right now after release of KDE SC 4.6.0 you start requiring libraries that will be around for 4.7.0.

And even tho you make things a bit easier for you as upstream developer because you just pull the given libs from head into your repository and bang things to compile that way you have to realise how much package maintainers you will make unhappy with this move.

As an example let me introduce you to nice image library called freeimage. It is quite nice library altho it bundles ALL libraries that are released separately in its tarball and it always is checked to built against them. So we as downstream maintainers waste quite of the time to update patchset with every release to make it build with system libraries. This is the amount of patches we introduce with every release <http://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=tree;f=media-libs/freeimage/files/3.14.1;h=21b0790cb948de7fefbe87426f97ffbd21d0f224;hb=HEAD>. Quite few distributions already removed the package from the main repo or lag behind few releases because simply nobody wants to mess and port forward those patches.

Hm, so why are some packagers not having an issue and simply pack digikam in a way that works?

And what difference would it make?

Scenario. You ship kdegraphics 4.4 and a digikam package that depends on it. Now the next digikam version depends on some libs that are part of KDE 4.5. Thus you have to package them and bundle them as openSUSE does, i.e. KDE 4.5 libs in an extra package installed along the 4.4 version which you have to keep for KDE 4.4 apps.

So let's say those libs would not be in kdegraphics but stand-alone. What would change? You would still have to keep the old libs from 4.4 around for KDE 4.4 and ship the new ones as a package.

And it's not like you double the libs. If the libs version of the installed KDE suits the digikam version they are used and no extra package is necessary. Only if they are not available via the installed KDE the bundled libs are used.

As I stated before and this does not depend on a special distro. Packaging digikam 1.8 or 2 for other KDE versions but 4.6 is possible and the packagers I know who even provide daily snapshots are not unhappy at all with digikam's current system.

Many distributions are not packaging the newer libs where there is a so called soname bump and the abi changes, thus avoiding conflicts...

Aah, so useless discussion...
Be sure to do whatever you want we will just whack it away or won't ship digikam, that sums it up.

(In reply to comment #17)
> Aah, so useless discussion...
> Be sure to do whatever you want we will just whack it away or won't ship
> digikam, that sums it up.

Blackmailing instead of offering the same service to your users as other distros do – nice!

What about putting your users first and following the example of other distros which are able to supply non-conflicting and perfectly working packages instead of blackmailing digikam devs to obey your way or whack their app? Pathetic!

(In reply to comment #18)
> (In reply to comment #17)
> > Aah, so useless discussion...
> > Be sure to do whatever you want we will just whack it away or won't ship
> > digikam, that sums it up.
> 
> Blackmailing instead of offering the same service to your users as other
> distros do – nice!
> 
> What about putting your users first and following the example of other distros
> which are able to supply non-conflicting and perfectly working packages instead
> of blackmailing digikam devs to obey your way or whack their app? Pathetic!

Blackmailing? Not at all. I tried to politely point out that budling libraries is NEVER the solution but you are not interested in it and obviously act really weirdly even on official medium like bugzilla.

If I would be blackmailing developers of digikam i would say something like "We wont ship digikam unless you package your stuff like we want it!". But no I SAID that we will do our best to package it for users obeying to all our QA standards or fail doing so and have to remove the digikam (not adhering to some set of QA rules usualy results in such, but I hope we will be able to do it anyway). I myself am user of the digikam and I wont stop using it just because some of you are people I obviously can't get along with, so given anything I want that thing working even for myself.

Rest is just result that your attitude on this bug is being total <pick your favorite offensive word> so i don't want to discuss any stuff with you any longer nor help you to do it proper way like i tried to do when i wrote first comment here.

(In reply to comment #19)
> Blackmailing? Not at all. I tried to politely point out that budling libraries
> is NEVER the solution but you are not interested in it and obviously act really
> weirdly even on official medium like bugzilla.
> 
> If I would be blackmailing developers of digikam i would say something like "We
> wont ship digikam unless you package your stuff like we want it!". But no I
> SAID that we will do our best to package it for users obeying to all our QA
> standards or fail doing so and have to remove the digikam (not adhering to some
> set of QA rules usualy results in such, but I hope we will be able to do it
> anyway). I myself am user of the digikam and I wont stop using it just because
> some of you are people I obviously can't get along with, so given anything I
> want that thing working even for myself.

Ah, your meant to be polite and do everything you can in order to ship digikam – my fault what I read was:

(In reply to comment #17)
> Aah, so useless discussion...
> Be sure to do whatever you want we will just whack it away or won't ship
> digikam, that sums it up.

So who is "we" and what's the polite meaning of "whack it away" or "won't ship digikam"? I'm sorry if I got confused and did not understand the proper meaning of those words which of course is "we will do our best to package it for our users even if digikam prefers another way of organising its sources".

> Rest is just result that your attitude on this bug is being total <pick your
> favorite offensive word> so i don't want to discuss any stuff with you any
> longer nor help you to do it proper way like i tried to do when i wrote first
> comment here.

Ah, so it was all me who made you say funny things in an aggressive way. I'm a really mighty person that I can put words in your mouth you did not mean to say and even make you write them down here.

I'll do my best to learn the new meaning of "whack it away" and "won't ship digikam" – promised!

Oh - and I refer back to comment 9 and comment 6.

Story continue on file #265328

Gilles Caulier