Building the Kolab Server (was: Re: What about starting to use project-builder for native packages?)

[Gunnar Wrobel]

Hi,

it has been some time since I thought about how we could build the  
Kolab server in the future. Especially if we move away from OpenPKG  
and focus more on the native variants of the server.

Whatever the main supported target will be my impression is that we  
will need to open up our build process to deal with more than a single  
build type. Which makes sense as we currently have a situation where  
the code repositories for the native installations do not reside  
within Kolab CVS. This is bad as it separates knowledge which I  
believe belongs together. At the same time the native distributions do  
not immediately benefit from updates or corrections in the main Kolab  
CVS.

My initial thought has been that project-builder would be a good  
solution to the problem. Using a tool specifically built for building  
packages for different distributions.

After looking a bit closer I think this might not be such a good idea.  
It would make it necessary for the devs to learn the semantics of just  
another build tool. And when I look at what I did with the PEAR  
packages and their Makefiles I would say we could probably achieve all  
that is necessary by just using such a templating approach together  
with make.

Coming back to Richards OpenSuse build service suggesting...

Quoting Richard Bos <ml at radoeka.nl>:

[snip]

> Some projects in the OBS use simple ad-hoc templating they have developed
> themselves that is specific to each package, eg a .spec.in file is processed
> on checkin to substitute variables from some template control using perl or
> sed scripts contained in the package to create a usable specfile.
>
> Others have developed domain-specific templating systems such as kde-obs-
> generator (http://en.opensuse.org/KDE/Build_Service/Cross-distro) that use an
> input template and the source's buildsystem to generate cross-distribution
> spec files for any project in that domain.
>
> I hope that also explains a bit the possibilities / limitations of the build
> service.

So this would mean that we could continue to develop stuff in Kolab  
CVS (or Kolab hg for that matter) and still build some variants of the  
Kolab server on the Suse build service? Then I would choose that way  
and even though we might not use the build service directly we would  
certainly try to allow for its use.

At the moment I think the best thing to do is to invite the native  
distros to criticize the way we currently build the Kolab server.  
Where are we causing problems for the native variants? Which packages  
could be easily transformed in a way that they can be built on several  
distros? Would that help anyone?

This way we might start on working to get away from OpenPKG while at  
the same time opening up on the other distros. And I believe starting  
that process is really urgent as we know we can't keep OpenPKG forever  
and the switch will cost a lot of effort.

Cheers,

Gunnar

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/users/attachments/20100614/82217796/attachment.sig>