[pkg-kolab] (Sort-of) forking Horde for Kolab?

[Mathieu Parent]

(I'm sorry to cross-post, but as the two lists are not too verbose I
prefer that everybody is aware).

Hello Horde and Kolab Debian packagers!

---------------------------------------------------------
(skippable ;)
First I start with a quick presentation:
The Kolab Groupware is made of different components:

The server part depends on
- OpenLDAP (or some other directory server),
- Postfix,
- a patched version of Cyrus (kolab-cyrus-imapd),
- Cyrus SASL to authenticate,
- the horde framework
- and optionnaly amavisd, clamav and spamassassin [kolab-server]

The server part is made of:
- the kolabd daemon (written in perl, and depending on libkolab-perl)
which creates mailboxes (and some other stuff),
- a postfix filter made in php (php-kolab-filter)
- and a php interface to retrieve freebusy (php-kolab-freebusy).

There is also a kolab-webadmin component that controls the LDAP
entries (this can also be done with other tools like GOsa).
All those Kolab server parts works good with current versions in
Debian testing [pkg-kolab-qa] (If not, fill a bug!).

---------------------------------------------------------
(skippable ;)
There are several clients [kolab-clients]:
- Kontact proko2 and enterprise4 (the version in Debian is from KDE,
some patches are not included: Maybe someone is interrested to help
include those patches?)
- Some proprietary clients (Outlook Connectors): we don't care in Debian
- a Thunderbird Plugin: SyncKolab that can be installed easily on
icedove (a Debian package is welcome).
- AND: a webclient based on Horde: here is the problem (see next section)

---------------------------------------------------------
The upstream Kolab web client is based on horde-webmail with a set of
patches (See [kolab-webclient-dev]). horde-webmail itself is an
agregation of various Horde apps including ramework, imp, turba,
kronolith, ... ([horde-webmail]).

Currently, kolab-webclient is based on horde-webmail 1.2.0 (I don't
know precisely the included app versions). Upstream is 1.2.4.

The patches for coming kolab minor version (2.2.3) are at:
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/horde-webmail/1.2.0/?only_with_tag=kolab_2_2_branch
The patches for the next version (2.3) are at:
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolab-webclient/patches/1.2.0/KOLAB/

My initial plan was to include all non-intrusive patches in the
different Horde packages. But this will be intrusive anyway. To
clearly indentify those patches, we can put a kolab-webclient git
branch between upstream+patches and debian-sid.

=> Is this ok for the horde packagers?

There is a special kind of patches which are "Config" patches. My
proposal for those is as follow:
- split all horde packages (app=imp4,kronolith2, horde3, ...) into app
and app-config.
  * app-config will contain all the /etc part and examples config.
  * app will depend on app-config (= ${source:Version}) | app-config-custom
  * app-config will conflicts with app-config-custom and recommends app
- the kolab-weblient package will provide app-config-custom, conflicts
with app-config
- all those packages will pass through the new queue.

=> Is this OK for horde packagers?

Any comments are welcome.

Regards

Mathieu Parent

[kolab-server]: http://kolab.org/about-kolab-server.html
[pkg-kolab-qa]:
http://qa.debian.org/developer.php?login=pkg-kolab-devel%40lists.alioth.debian.org
[kolab-clients]: http://kolab.org/about-kolab-clients.html
[kolab-webclient-dev]: http://wiki.kolab.org/index.php/Horde_development
[horde-webmail]: http://www.horde.org/webmail/