[Digikam-devel] Re: [Kde-imaging] Re: Re: Git migration for 2.0.0 + code components re-structuring...
caulier.gilles at gmail.com
Sat Dec 11 12:30:05 GMT 2010
But i already worklike this on my system. both, official package and
devel libraries are installed in /usr. there is not conflicts because
ABI and API are increased into devel. libraries soname are not the
same. I think it's work fine.
I will prepare svn GoSC2010 branche like this and let's you test in
your computer to see if all i fine. Especially, if options that i will
add to cmake will be fine to compile/install 3rdparty components
independantly and digiKam as stand alone, using shared libs provided
by the system.
I will move back libkmap and libkface from kdereview to GoSC2010
branch today to prepare 2.0.0 source code using this schema.
also, the time to lets libkmap and libkface have been enough i think...
Later, if we want to share this libraries at the right place to kde
core, we can do it as well to copy 3rdparty folder on kde components.
2010/12/11 Angelo Naselli <anaselli at linux.it>:
> In data giovedì 9 dicembre 2010 18:18:19, Gilles Caulier ha scritto:
>> 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.
> You need to take care also that the version you release out of trunk
> *have* to be upgraded by the next trunk (e.g. kdegraphics stable) version
> to avoid conflicts.
> Remember that a system that installs libfoo from a standalone package
> can have conflicts when updates libfoo using another package.
> I mean libkipi-kdegraphics and libkipi-standalone are in conflicts if
> they produce same files in same position...
> And certainly packager have to take in account the developer
> version of that library...
> Kde-imaging mailing list
> Kde-imaging at kde.org
More information about the Digikam-devel