[Kde-pim] kdepim runtime

Volker Krause vkrause at kde.org
Wed Jun 17 08:00:36 BST 2009


On Wednesday 17 June 2009 02:16:38 Allen Winter wrote:
> On Tuesday 16 June 2009 10:48:09 am Allen Winter wrote:
> > On Thursday 07 May 2009 5:47:03 pm Tom Albers wrote:
> > > Hi DIrk, *
> > >
> > > As discussed today, we would like to have a kdepim-runtime tarball, we
> > > would like to have it contain the content of /trunk/KDE/kdepim/akonadi.
> > > It should be able to compile stand alone and only contains the stuff
> > > that is a runtime dependency for akonadi application.
> > >
> > > That way for example Mailody can depend on that package instead of
> > > depending on the whole of kdepim.
> > >
> > > We should decide about the renaming kdepim/akonadi to
> > > kdepim/runtime/akonadi or we could create a kdepim-runtime next to
> > > kdepim as top level folder. I really don't care about what solution
> > > will be taken as I can not oversee the build consequences at all. So I
> > > think the experts should give their opinion about that.
> > >
> > > I hope we can do this for the 4.3 releases. Does not have to be for the
> > > tagged beta of course, althought that would be nice for the packagers
> > > to adapt to the change.
> >
> > PIMSters,
> > How are we doing on this?
> >
> > The RC1 tagging is coming in about 1 week.
> > We need a complete separation of kdepim-runtime code in place before
> > then.
> >
> > Last I heard, there were still 2 blockers of stuff in kdepim/akonadi that
> > was dependent on other areas in kdepim.
> >
> > Please advise on the status of this project.
>
> After talking to Christophe, Volker, and Thomas today, we have the
> following plan:
>
> 1) put copies of the 2 blocker classes from kdepim/libkdepim into
> kdepim/akonadi. they will be clearly marked as copies that need to die and
> be reborn in kdepimlibs. This should allow all of akonadi to build without
> any other parts of kdepim.
>
> 2) create 2 top-level subdirs: runtime and apps (sound familiar?)
> Move akonadi, strigi-analyzers (and maybe kresources and plugins)
> into the new kdepim/runtime.  Move everything else into kdepim/apps

I suggest to just rename akonadi to runtime then, we don't need the extra 
level of directories there. If possible packaging-wise I would also suggest 
to omit the apps directory and leave that stuff on top-level, otherwise 
branch-maintenance will be a nightmare. Keep in mind that we have half a 
dozen active branches with merge tracking to trunk! At least wait until trunk 
is open again, then we can merge the work branches (soc, akonadi ports) 
first, leaving only the 4.x and enterprise branches.

Regarding moving kresources and plugins: None of those are currently movable 
due to their dependencies (plugins depends on KMail, kresources at least on 
libkdepim). So, I suggest we ignore those for now, kresource will eventually 
go away anyway.

> 3) kdepim/CMakeLists.txt will basically become a 2-liner:
>    add_subdirectory(runtime)
>    add_subdirectory(apps)

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


More information about the kde-pim mailing list