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

[Gilles Caulier]

All move are done with commit #1205541.

Please checkout source code in GoSC2010 branch :

http://websvn.kde.org/branches/extragear/graphics/digikam/

I will prepare all lead CMakeList.txt files

Gilles Caulier

2010/12/11 Gilles Caulier <caulier.gilles at gmail.com>:
> yes, right.
>
> 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.
>
>  Marcel, Michael,
>
> 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.
>
> Gilles
>
> 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...
>>
>> Cheers,
>> --
>>        Angelo
>>
>> _______________________________________________
>> Kde-imaging mailing list
>> Kde-imaging at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-imaging
>>
>>
>