new pim stack (transition finally went through)

[Harald Sitter]

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