Heya to make sure everyone knows a thing or two about our new mad pim stack let me quickly outline things involved. Actually, let me outline it quickly but it will still be a very long mail. sorz.
Firstly kdepim4 is gone from the archive as it can not be co-installed with the new pim stack and the two stacks do not share data but akonadi uses the same directories, so things could weirdly implode if we were to allow mixing runtimes in any capacity. # kde-sc 4 compatibility ## akonadi1 - locked at version 1.13 A compatibility source providing the library package libakonadiprotocolinternals1 (along with libakonadi-dev) which is used by kde4pimlibs to use akonadi. Akonadi1 has an intentionally defunct runtime. It does not build any runtime parts (i.e. akonadi-server) as these would conflict with the new Akonadi which unfortunately enough has a different wire format (i.e. the old akonadi lib cannot use the new runtime). This has the unfortunate downside that software that expects a working akonadi-server will not function correctly with our stack. While unfortunate this isn't something we can do anything about. And worse yet, due to how applications linked *all* kdepimlibs we do not know which directly depend on akonadi technology as all of them link against akonadi bu that doesn't mean they use it. ## kde4pimlibs - locked at version 4.14.10 A compability source providing the entire set of previous packages from kdepimlibs. These libraries (except libakonadi-kde4) are expected to work as before. The data they work on is not shared with the kf5 counter parts though so much like kwallet4 they are essentially a dead end. # new akonadi New akonadi source is creating a new akonadi-server which is pretty much featuring the same runtime lineup as we had previously (i.e. forcefully wants mysql but can have other backends added because akonadi does not allow auto-migration of backends so mysql must not be lost ever). This is the one and only akonadi-server we have now. It is compatible with all new libs but not with the old ones. Also this will eventually (nobody knows when) get replaced by an entirely new better designed implementation of akonadi, nothing to worry about for now though. # new libraries - kdepimlibs kdepimlibs is vastly reduced from what it was in kde4 as most things were split out. - akonadi-calendar - akonadi-search - kalarmcal - kblog - kcalcore - kcalutils - kcontacts - kholidays - kidentitymanagement - syndication - ktnef - kpimtextedit - kontactinterface - kmime - kmbox - kmailtransport Most of these were split from kdepimlibs All of these new libraries should be packaged in accordance with multiarch standards. They are mostly tiny one-library packages making them vastly more manageable. # new runtime ## kdepim-runtime Not co-installable port of 4.x version of runtime assets. Along with akonadi-server this forms the concerning runtime part of the transition. In 4.x kdepimlibs would force kdepim-runtime into all applications that linked against any one kdepimlibs library meaning we simply do not know what actually might have required kdepim-runtime, so it is possible that 4.x-using applications might have problems after this transition since they can no longer find the assets they require from kdepim-runtime. ## kdepim Pretty much a straight port from the 4.x version with soversions bumped. The applications knode and kjots are gone, along with the mobile applications UIs. # Future - There are still a bunch of improvements to be made to kdepim* - kdepimlibs restructuring bin/akonadi* for better MA support - put akonadi2xml and knut resource into dev-tools package as they are mostly useless - kdepim-runtime needs bdep on libkolab & libkolabxml - kdepim needs bdep on libkolab & libkolabxml - Applications 15.12 will need at least a partial library transition as libraries already broke ABI again - akonadi will eventually get changed for a completely new code base which likely will need a full transition again, although I hope the kdepim team works out a soft-migration for that as to not break every application that appears until then. HS -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
