[Kde-pim] Intra-module dependencies in kdepim
    Tom Albers 
    toma at kde.org
       
    Mon Oct  5 18:22:04 BST 2009
    
    
  
Op Monday 05 October 2009 16:51 schreef u:
> Possible solutions: experimental library as part of kdepimlibs like it has 
> been done for KNotificationItem or copies in every module that uses it. Since 
> we only have four at most (apps, runtime, extragrear, playground), temporary 
> copies and more aggressively pushing to kdepimlibs seem the least ugly 
> solution to me.
I would go for the solution of putting it in pg. As soon as two apps use it, and the release cycle is < feature freeze, move it to kdepimlibs and polish there.
> libkdepim: A total nightmare as nearly everything uses it.
> - do not allow to put new stuff in there
 +1000
> The goal would be to have less and less components depending on libkdepim 
> which gives us more freedom when moving stuff around and avoids the libkdepim 
> copy in the runtime tarball.
Sounds like a good plan. I would like to even go a more aggresive approach in trying to remove it completely asap (after apps are ported to akonadi).
> akonadiconsole: ended up in runtime, due to the dependency mess. Should IMHO 
> be moved back to apps.
+1
> examples: there are a bunch of examples in akonadi/clients, more are part of 
> the upcoming merges from the akonadi-ports branch. They should be independent 
> of internal/non-installed libs and eventually moved to the kde-wide example 
> module IMHO. Even if that will not be created (I haven't seen the result of 
> that discussion yet), our examples should probably not be in the runtime 
> module, kdepim/examples maybe? or somewhere in playground/pim?
I've created http://websvn.kde.org/trunk/KDE/kdeexamples/ earlier, just nothing in there yet.
> Now on to the new stuff: I'm about to merge the current state of 
> libmessageviewer from the akonadi-ports branch. That's the Akonadi/KMime port 
> of the message viewer of KMail, extracted and made a stand-alone library 
> (depending, among other things, on libkdepim, libkleo and libkgpg, ie. three 
> libs in kdepim/apps, not movable to kdepimlibs currently). Besides KMail (and 
> hopefully KNode) this will also be used by the Nepomuk email feeder agent, to 
> do message decryption. With the feeder agent currently in kdepim/runtime, you 
> can see what made me think about the dependency mess in the first place ;-)
Move the 3 gpl libs to kdepimlibs is the solution, right?
> Despite obviously belonging into kdepim/runtime the only possible solution I 
> can see currently is to move the feeder agent to kdepim/apps. It shares a 
> small amount of code with the agents for contacts and calendar, this would 
> need to be copied for now. Some of this is at least supposed to end up in 
> libraries eventually.
That would remove nepomuk feeder usage for pg/eg users. I don't think I care much at this moment in time though.
> To at some point move it back to runtime we would need to get rid of its 
> libkdepim dependency, get rid of the deprecated libkpgp and make libkleo and 
> libmessageviewer API-stable and move them to kdepimlibs, so this is only a 
> very long term option.
If you put it in there it will get even harder to move it out imho.
Best,
Toma
-- 
KDE Developer
-------------- 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