[Digikam-devel] Fwd: [Kde-imaging] Re: Re: Git migration for 2.0.0 + code components re-structuring...

Gilles Caulier caulier.gilles at gmail.com
Thu Dec 9 17:18:29 GMT 2010

---------- Forwarded message ----------
From: Gilles Caulier <caulier.gilles at gmail.com>
Date: 2010/12/9
Subject: Re: [Kde-imaging] Re: [Digikam-devel] Re: Git migration for
2.0.0 + code components re-structuring...
To: kde-imaging at kde.org

2010/12/9 Angelo Naselli <anaselli at linux.it>:
> giovedì 9 dicembre 2010 alle 15:49, Gilles Caulier ha scritto:
>> I know that Mandriva backport trunk/unstable but it's not the case of
>> debian ubuntu, and fedora, which won't to do work in this way. They
>> want to backport unstabilized code in all case. It's a logic goal...
> bah, logic? what's logic in having an unstable system if you're not e tester?
> I don't mean digikam is unstable, and anyway if someone wants to have last release
> of all in his distribution can always backports all he needs.

The logic is to always use stable version of kdegraphics/libs in a
distro. This is a right proff of quality.

Mixing unstable code with stable code from KDE core sound like
dangerous for packagers. This is what DEbian, Ubuntu and Fedora
packager said to me by private mail or in bugzilla.

Of course i tried to convince packagers that this unstable code can be
used in production but without any sucess.

As Martin said previously, this is not the better way to deal with
distro to force to include unstable code in production.

> I don't talk about mandriva, i just talk about a way of thinking (mine of course ;)).
>>Why not to try a digiKam package as explained before, without to fork
>>unstable libkexiv2, libkdcraw for the moment ? We can see if it's
> We can move every libkxxx we need, but if we share one of them with
> someoneelse (kdegraphics for instance) we must take that in account.

yes of course...

But as i tried to explain before, the goal is not to remove libkexiv2
and libkdcraw from kdegraphics/libs.

The goal is to host the current unstable code from trunk in digiKam
package and use it with the digiKam and co release. This copy of
unstable code will have API/ABI id increased to be installed in both
to the system without to break anything.

The current stable will not be in conflict with unstable version. When
unstable become stable, we copy this code to next trunk KDE, and we
start new unstable with digiKam... Do you understand what i mean ?

> We cannot do what we want and we have to decide if depending on trunk
> ("unstable") or branch (should be stable).

sure, and i really at the good place to take a choice, but to convice
packagers it's another story... And i have don't much time to trying
to change policy of linux distro.
> Anyway deciding to move libkxxx from kdegraphics to digikam (or extragear,or...)
> should be decided also with all that projects that need them...

As i explain before, we will never remove these shared libs from
kdegraphics. For 3rd party applications which use it, nothing will


More information about the Digikam-devel mailing list