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

[Volker Krause]

On Saturday 23 June 2012 14:36:20 Kevin Ottens wrote:
> On Saturday 23 June 2012 02:17:58 Christian Mollekopf wrote:
> > On Friday 22 June 2012 17.28:14 Sune Vuorela wrote:
> > > On 2012-06-22, Christian Mollekopf <mollekopf at kolabsys.com> wrote:
> > > > 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.
> > > 
> > > I'm pretty sure the plan is to split up (most of) kdepimlibs as
> > > independent frameworks once the frameworkified (is that a word?) kdelibs
> > > is getting ready for a release.
> 
> Yes, latest discussions on the topic were that kdepimlibs would enter the
> KDE Frameworks offering not before 5.1. If it's mature enough fast enough
> it could be in KDE Frameworks 5.0 of course, but seeing the current pace I
> doubt it.
> > > What's your timeframes?
> > 
> > About a month from now =P (not sure when it actually get's critical).
> 
> Unrealistic I'd say (at least if we assume it's on top on kdelibs/frameworks
> branch in its final form).
> 
> > We certainly need some solution before frameworks though (kimap & kcalcore
> > are most pressing currently).

the libraries in pimlibs are already fairly stand-alone, your problem will be 
the kdelibs dependencies and the stuff pulled in that way I think.

> > Maybe it would be possible to already do the split in a branch, which can
> > depend on a reasonably low kdelibs (4.3), in a way that the result of that
> > can then actually be used when kdepimlibs is ready for a split.

The most important stuff used from kdelibs are KTcpSocket (imap) and KDateTime 
(kcal) I think, for none of which you want outdated versions (if they are 
available in 4.3 at all). To make this work on a 4.3 kdelibs I'd expect you 
end up shipping copies of those and by-pass the ones from kdelibs, which is 
very painful and in no way reusable for the version 5 frameworks work.

> > I suppose I could maintain such a branch and port patches, until we're
> > there
> You'd have to be very careful that it's aligned with the bigger kdepimlibs
> plans of course. But having a frameworks branch in kdepimlibs isn't that far
> from what we're doing in kdelibs...

There's already one btw, used for porting kdepimlibs to the kdelibs frameworks 
branch.

> Having it based on an old kdelibs I'm
> less certain it's a good idea though. I think a rather large chunk of the
> frameworkification (thanks Sune for the neologism) for kdepimlibs will be
> adjusting the buildsystem (at least in the parts you're most interested
> in), none of that work will happen with an old kdelibs (where kdecore,
> kdeui and friends still exist).

Exactly.

> > At least that is the only idea I have how to solve that issue, without
> > copying code to our own libraries and doing patchwork there (which seems
> > like a waste of time to me if I could do upstream work during that time).

Unless you can use pre-release kdelibs frameworks (assuming there are some 
that have the parts you need split out already), I don't see this aligning 
with KF5 work much.

regards,
Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120625/b4cf6ee3/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/