Bug 252964 - Please remove libs from kdegraphics and make independant
Summary: Please remove libs from kdegraphics and make independant
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-DImg-RAW (show other bugs)
Version: 1.4.0
Platform: Fedora RPMs Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-01 21:15 UTC by Simon Lewis
Modified: 2017-07-24 09:04 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.0.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Lewis 2010-10-01 21:15:59 UTC
Version:           1.4.0 (using KDE 4.4.5) 
OS:                Linux

Hi Digikam Team

I have a very stable KDE 4.4.5 running on Fedora 12 and I am forced to use Digikam 1.2.0/Kipi plugins 1.2.0...

Fedora 13 users also have the same problem - namely the kdegraphics/libs which aren't actually KDE version specific are tied to the KDE version through the kdegraphics dependancies.

Neither fedora nor rpmfusion are supporting Digikam 1.3.0 or 1.40 on Fedora 12 or Fedora 13. Arghh!!!

Please remove these libs from KDE SC and make an independant libary package so that all users can enjoy the latest digikam releases by installing from repos..


Reproducible: Always

Steps to Reproduce:
Try building am rpm from kipiplugins source code package..!

Actual Results:  
Build fails at start on dependency check specifically libkdcraw, libkexiv2 and opencv are not current enough in kdegraphics 4.4.5

Expected Results:  
Should be possible to build kdegraphics, libkdcraw, libkexiv2 and opencv independently...
Comment 1 Martin Klapetek 2010-10-02 11:44:57 UTC
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/
Comment 2 Marcel Wiesweg 2010-10-02 14:16:09 UTC
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
Comment 3 caulier.gilles 2010-10-02 15:17:33 UTC
and now, Plasma components use libkexiv2 to play with image metadata, as slideshow and desktop background...

Gilles Caulier
Comment 4 Simon Lewis 2010-10-04 19:02:13 UTC
(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
Comment 5 Simon Lewis 2010-10-04 19:21:26 UTC
(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!
Comment 6 Marcel Wiesweg 2010-10-04 20:53:26 UTC
> 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 ;-)
Comment 7 caulier.gilles 2010-12-13 13:03:05 UTC
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
Comment 8 Tomáš Chvátal 2011-01-28 22:01:36 UTC
(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
Comment 9 Julien Narboux 2011-01-28 22:44:10 UTC
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
Comment 10 Simon Lewis 2011-01-29 12:45:59 UTC
(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.
Comment 11 S. Burmeister 2011-01-29 14:39:55 UTC
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.
Comment 12 Simon Lewis 2011-01-29 17:27:44 UTC
(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
Comment 13 S. Burmeister 2011-01-29 18:20:16 UTC
(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.
Comment 14 Tomáš Chvátal 2011-01-29 18:47:49 UTC
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.
Comment 15 S. Burmeister 2011-01-29 19:20:03 UTC
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.
Comment 16 Simon Lewis 2011-01-29 19:28:31 UTC
Many distributions are not packaging the newer libs where there is a so called soname bump and the abi changes, thus avoiding conflicts...
Comment 17 Tomáš Chvátal 2011-01-29 20:05:32 UTC
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.
Comment 18 S. Burmeister 2011-01-29 20:12:15 UTC
(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!
Comment 19 Tomáš Chvátal 2011-01-30 20:08:03 UTC
(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.
Comment 20 S. Burmeister 2011-01-30 20:27:05 UTC
(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.
Comment 21 caulier.gilles 2011-02-08 10:44:20 UTC
Story continue on file #265328

Gilles Caulier