[Kde-pim] Kolab usage of kdepimlibs, kdepimlibs split

[Christian Mollekopf]

Hey,

I looked into using a preleminary version of frameworks, but there are a 
couple of problems, like the required cmake version or that there still 
remains the need for libkdecore. Generally just too many dependencies, and I 
would still have to check that it actually works with qt 4.6.

So it looks, sadly, like I will have to copy paste together a library 
containing the required kdecore/kdepimlibs libraries (which I hope I can make 
work with qt 4.6).

Of course that is a temporary workaround, but I see no other solution (at 
least not one that is any better) until kdeframeworks.

I'll see that I develop against kdepimlibs anyways and just port the patches 
to my copy and hope to survive this way until I can get rid of this mess 
again.

In case you are aware of a solution that does also work on relatively outdated  
systems (some call it stable), and doesn't require shipping loads of extra 
(updated) packages, a hint would be much appreciated.

Cheers,
Christian

PS: If somebody feels like giving me a heads up on what is required to get 
kcalcore and kimap ready for frameworks during akademy, I'd be interested.


On Friday 22 June 2012 19.07:15 Christian Mollekopf wrote:
> Hey,
> 
> For Kolab 3.0, we're trying to reuse some of the relevant kdepim
> infrastructure also on the server, specifically:
> - kcalcore
> - kimap
> - kmime
> - kabc
> 
> We do have the problem though of the huge dependency chain pulled in by
> kdepimlibs + kdelibs, as well as the problem of not being able to make new
> releases of said (sub-) libraries.
> 
> Especially now in the beginning I have to add some fixes/new functionality,
> and we need a way to get that on the server in the end.
> 
> The preferred way forward is pulling those libraries out of kdepimlibs,
> along the lines of what is happending for frameworks, with only the
> dependencies which are really required.
> 
> That would allow us to package & ship the packages we require for our target
> platforms (which is eg Enterprise Linux 6 currently on kde 4.3 and qt 4.6).
> 
> Now I can imagine that this is something which is generally planned to be
> done after frameworks is released (as we'd also rather have the strapped
> down frameworks dependencies), but I'd be interested to learn how we can
> speed-up that process and maybe have an intermediate solution, without it
> being a completely separate effort.
> 
> After all we really don't want a fork or alike and want to work as much as
> possible upstream.
> 
> So are there already plans, or suggestions in what direction such a task
> could be tackled?
> 
> I'm at akademy with Jeroen van Meeuwen, who is our Systems Architect with
> Release-Engineering skills, so it would be a good occasion to have a chat on
> how to continue in that respect, and what we can do already now. If you're
> interested/willing to help, tell me.
> 
> Cheers,
> Christian
> 
> PS: I'm the same as chrigi_1 at fastmail.fm =)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120626/faa15478/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/