Hello, On trečiadienis 09 Birželis 2010 01:14:10 Mark Purcell wrote: > > Just compile and install libkdcraw/libkexiv2 (and also libkipi) from > > svn trunk (kdegraphics module) > > Gilles, > > Unfortunately for a distribution such as Debian we are tied to releases of > the kdegraphics module. We can't easily include the svn trunk components > of some of kdegraphics :-( > > > all library code are managed by digiKam team. > > The libraries maybe managed by the digikam team, but the release is > controlled by the kdegraphics release, do you know which release the > updates are slated for? > > I would doubt that KDE SC 4.4.5 will include large changes, which means we > maybe awaiting KDE SC 4.5 for updates to these libs. If digikam developers can't wait for the dependent libraries to become stable (KDE SC 4.5 release) before making *stable* digikam release depend on them, there is something really wrong with their release management. Moreover, applications try to depend on (current KDE SC stable - major 1) release in order to ease the pain for distributions and poor users compiling from source. If anything, current situation just decreases availability of the new digikam release. Debian is not going to pull kdegraphics (or parts of it) from "svn trunk", just because a random application (digikam) needs it. Please fix the problem in the proper way (see below). > Previously when the digikam team released these libraries directly, we > could update the library packaging independent of the upstream kdegraphics > release, however we cannot do that anymore. Then I don't understand what those libraries are doing in kdegraphics anyway. In fact, it is not the first time (and probably not the last) this happens. Just move the libraries to extragear or kdesupport where apps/libraries may have their own release cycle, release those libraries with new stable digikam if it needs them and be done with these issues once and for all. Or alternatively please at least depend on the current KDE SC release if any distro friendliness is your goal. To sum up, IMHO, in this case shipping with digikam 1.2 is not a big deal. Or maybe patching digikam code could an option if the patch does not end up being intrusive. In any case, it's just a pity that such (basic I would say) release management issues prevent us from shipping the latest :/ > I presume that other distributions would also have the same issues? Oh yeah, I see them loving it. -- Modestas Vainius <firstname.lastname@example.org>
Description: This is a digitally signed message part.