With Horde4 the old "framework" block of code contained in the base
Horde application will be split into its single component parts.
This should help to underline the modular framework aspect of Horde
itself.
The Kolab Server is one of the few systems that tried to use part of
the Horde software stack even with Horde3. Both the free/busy system
and the Resource management do not require more than a few packages
from the Horde core framework.
With Horde3 this approach has always been somewhat awkward. The Horde
release process made no use of the fact that the Horde framework was
split into modules. With the Kolab Server we had to work around
this limitation which resulted in the split packaging layout which
will be available with Kolab-Server-2.3. But this is hand made on the
Kolab side.
For Horde 4 p@rdus is pushing the use of PEAR with a specialized
"component helper". The idea is to facilitate the handling of many
small Horde components - each a PEAR package.
The tool currently allows automatic updates to Horde component
manifests. It packages development snapshots. Builds continuous
integration configuration for a component. It creates packaging specs
for a distribution - and lists package dependencies.
Last but not least: It install components. And it does that primarily
based on the code repository.
This is an essential feature for the continuous integration setup as
all testing of the newest code will happen based on installed
components. As a result the packaging will automatically be part of
the quality control. Both the developers as well as the packagers will
benefit from that.
Once the complete components setup is in place it will be very easy to
derive a set of packages from it. Whether these packages are targeted
for OpenPKG (Kolab Server 2.2.4 or 2.3) or some later native packaging
will not really matter. p@rdus is of course actively working on such
packaging and you can watch for commits on the horde4 branch of the Kolab server
mercurial repository.