[Kolab-devel] Should we switch to one big bloated kolab package?

[Gunnar Wrobel]

Hi!

As mentioned in one of my last mails we have better upstream access
now and can manage our package definitions directly within OpenPKG
CVS.

This is quite nice since we don't need all those patched package
definitions any more and Kolab CVS is now rather uncluttered. At least
if I disregard all the empty folders visible in ViewCVS which make it
a bit hard to find the source code in our CVS :) Anyway there are now
nearly no patched specs in CVS anymore and instead we collect all
Kolab Server specific patches here:
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/

Now I was considering the possibility of also managing the package
definitions for the Kolab specific packages like perl-kolab,
php-kolab, kolabd etc. in OpenPKG CVS. But OpenPKG has a policy to not
add too many new packages which might get removed at a later point
again. They are also using CVS and don't want their ViewCVS to look
like ours after a while. Might also be other reasons, I'm not
certain. Anyhow it does not seem an option to move all RPM specs from
Kolab CVS into OpenPKG CVS. But OpenPKG asked me if it would be
possible to just have a single package. In fact that was probably the
original plan some years ago because there exists a single package
called "kolab" already in OpenPKG CVS (and in our CVS too).

This may look like an ugly option first but let me explain why I would
still like to consider this option.

The main advantage I can see if we move over to OpenPKG CVS is the
possibility to use their build farm. This way we can not only test our
build/installation procedure on about 15 different Linux distros but
we can also provide the compiled binaries for these. The possibility
to actually test run on fifteen different base systems is something
that I'd value.

In addition it would be possible to provide direct OpenPKG
installation instructions. This way people that have build errors with
an older Kolab release can use the newest base packages from
OpenPKG. Many of the build problems experienced with stable Kolab
releases are often already fixed in the updated OpenPKG packages. So
this would allow easier workarounds.

Finally it would further reduce the stuff we keep in our CVS system
and all that would remain would be the real Kolab specific source
packages. I'd probably keep the "kolab.spec" file of the "kolab"
package in there as a duplicated reference too.

The drawback of this is that we would have one big package (and I mean
BIG!) that installs perl stuff, php stuff, webapps, templates in one
go. It would contain perl-kolab, php-kolab, kolab-filter,
kolab-freebusy, kolabconf, kolab-webadmin, kolabd, pear/*, and
horde/*. Of course the Horde stuff would be optional using the
"with_horde" flag.

I guess anyone that does packaging might consider this insane. At
least the Gentoo developer part inside me is screaming "Sin! Sin!
Sin!" :) But I nevertheless believe that the advantages really
outweigh the disadvantage of having this one bloated package.

This would of course mean no disadvantage to the native
installations. In fact this would require to distribute source
packages only. And you can bet that you'll always have twenty packages
for Kolab2/Gentoo even if there is only one for Kolab2/OpenPKG ;)

What do you think?

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 40 432 72335                           Bundesstrasse 29
Fax    : +49 40 432 70855                            D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~