KTp/Packaging Guide: Difference between revisions
| Line 25: | Line 25: | ||
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-chat-handler telepathy-chat-handler] (Required) '''''Should we change the name of this repo to be the same as the new name for the app?''''' | * [https://projects.kde.org/projects/playground/network/telepathy/telepathy-chat-handler telepathy-chat-handler] (Required) '''''Should we change the name of this repo to be the same as the new name for the app?''''' | ||
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-contact-list telepathy-contact-list] (Required) | * [https://projects.kde.org/projects/playground/network/telepathy/telepathy-contact-list telepathy-contact-list] (Required) | ||
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-presence-dataengine telepathy-presence-dataengine] ( | * [https://projects.kde.org/projects/playground/network/telepathy/telepathy-presence-dataengine telepathy-presence-dataengine] (Required for correct functioning of the presence applet, highly recommended) | ||
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-presence-applet telepathy-presence-applet] (Optional, highly recommended) | * [https://projects.kde.org/projects/playground/network/telepathy/telepathy-presence-applet telepathy-presence-applet] (Optional, highly recommended) | ||
* [https://projects.kde.org/projects/playground/network/telepathy/telepathy-filetransfer-handler telepathy-filetransfer-handler] (Optional, highly recommended) | * [https://projects.kde.org/projects/playground/network/telepathy/telepathy-filetransfer-handler telepathy-filetransfer-handler] (Optional, highly recommended) | ||
Revision as of 14:28, 15 July 2011
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.
Upstream Packages
Two upstream packages are essential for KDE-Telepathy to work.
- telepathy-qt4 >= 0.7.0 (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).
KDE-Telepathy Packages
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?
Ready Components
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 (Required for correct functioning of the presence applet, highly recommended)
- telepathy-presence-applet (Optional, highly recommended)
- telepathy-filetransfer-handler (Optional, highly recommended)
- telepathy-send-file (Optional)
Experimental Components
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.