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

[Gunnar Wrobel]

Thomas Arendsen Hein <thomas at intevation.de> writes:

> * Gunnar Wrobel <wrobel at pardus.de> [20071017 10:46]:
>> 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 ;)
>
> One big package means that you can't repleace parts of the server,
> e.g. to just upgrade the horde components on a server otherwise
> running a constant kolab version, or just the web admin interface to
> get updated translations,

Exactly. This is something one couldn't do that easily. I regard that
as a minor disadvantage since I have the impression that
Kolab2/OpenPKG has always been distributed as single, combined
installable version. I doubt many users update single packages (with
the exception of sec issues of course).

It would also be possible to have two or three packages. I admit that
the web applications you are referring to are indeed more prone to be
updated in a separate fashion.

> or just deinstall the web admin interface
> to use your own solution (or have the web interface or horde only
> available on one of many servers).

This would still be possible since the main package could have options
like "with_horde", "with_fbview", "with_admin".

The whole thing should of course have no effect on the Kolab
programming style. Many of my recent commits were concerned with
moving the source into the exactly opposite direction (e.g. breaking
packages apart, making them less dependent on each other). This
separation on the source level is something I regard as vital for a
clean code base and I'm definitely not suggesting moving backwards
again. But on the packaging level of Kolab2/OpenPKG I think this would
be a useful thing to do.

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 <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~