Packaging KDE-Telepathy is complicated for two reasons: firstly, due to the modular nature of Telepathy, there are several distinct components in separate git repositories. Secondly, there are large numbers of runtime interdependencies to worry about. This page attempts to ease packaging KDE-Telepathy in a useful way by explaining these issues.
Two upstream packages are essential for KDE-Telepathy to work.
- telepathy-qt4 >= 0.5.15 (Build and Runtime Dependency)
- telepathy-mission-control >= 5.7.9 (Runtime Dependency)
The IM networks that KDE-Telepathy can connect to are decided by which Telepathy Connection Managers are installed. These are runtime only dependencies, but which ones are installed will decide what IM networks KDE-Telepathy supports. The following are the ones we recommend - whether they are installed optionally or required is, of course, up to you.
- telepathy-gabble (for Jabber support, including Google Talk and Facebook)
- telepathy-butterfly (for MSN/Windows Live support)
- telepathy-haze (for all the other protocols, as supported by libpurple).
The different components of KDE-Telepathy are housed in separate git repositories on projects.kde.org. Some of these components are currently recommended to use. Others are not yet ready to be installed by users.
Should we recommend adding a "kde" somewhere in the names of the KDE-Telepathy packages to avoid confusion with upstream/non-KDE stuff?
These components have reached a level of maturity where they are interesting to users. We recommend providing these components at the current time.
- telepathy-accounts-kcm (Required)
- telepathy-accounts-kcm-plugins (Optional, highly recommended, could conceivably be separated out into one package per CM plugin)
- telepathy-approver (Optional, but highly recommended)
- telepathy-chat-handler (Required) Should we change the name of this repo to be the same as the new name for the app?
- telepathy-contact-list (Required)
- telepathy-presence-dataengine (Optional, highly recommended)
- telepathy-presence-applet (Optional, highly recommended)
We have several other components under development, however, unless they are listed above we do not recommend packaging them. This is because they are subject to major changes/removal at any time, and are not ready for end users yet.