Modularization (Portability)

[dual_prophet]

I was wondering if there were any future plans to modularize zimbra into a single package, with dependancies on existing verions of system packages (tomcat, mysql, clam, etc). I think having minimum package requirements & sanity checks in the install script is much less work than maintaining multiple individual installs of software packages (security patches, optimizations, all become an additional burden). If this platform utilized it's own chroot environment for security, I would understand the need for the multiple installs, however this is currently not the case. As far as I can see zimbra has no architechture specific code in the "meat" of the program, just the services/apps that it depends on. I think that affects the portability of zimbra. Adapting to a pre-existing stable environment is much more logical and convenient than re-inventing the wheel so-to-speak with your own binaries. I have installed zimbra on red hat 7.3, 9, fedora 1, and 2, all of which are unsupported, and the process of adapting zimbra to those systems involved directing zimbra to the pre-existing installed packages and data. I noticed in install.sh:

SOFTWAREONLY="no"

Is this initial work on doing a software-less install?

Are there any compile-time optimizations to these packages that are zimbra-specific?

Forgive me for any hindsight, and I look forward to your thoughts on the subject.

[KevinH]

This topic comes up ever so often. Good set of reasons here:

Fat Distribution Decision

We do pass some special compile time flags to some of the builds, and spent sometime getting SSL to play nice across all the pkgs. The only patches we add are to Cyrus-SASL though. The biggest problem with using existing pkgs is the ability to reconfigure those would involve major changes to our various scripts and admin utilities.

In the end it's something we want to do but it's lower down on the list today.