1

Topic: Package choices and why outside the package management system

Zhang,

I have a question that may be answered elsewhere that I haven't been able to find. Is there a list of the packages along with a description of why that particular version/package was used?

I'm trying to get into the internals of the system and some choices are not apparent. I'm looking for things like why you choose the apache2-mpm-prefork package which is the non-threaded version, I'm not a aware of a reason this would be better, but you've clearly got a reason. Another example would be packages that aren't using the package used by the distribution. Such as in my case the Debian wheezy version of Roundcube. Such choices forgo the package management system and the security updates it brings. I haven't reviewed this one closely but I don't see an obvious reason for that.

It would be particularly handy if there was a list somewhere of all the packages iRedMail (& iRedMail-AdminPro if there are any additional packages outside your custom code) use, why this particular package/version was chosen, and in particular where packages aren't using the systems default package management why this is the case.

Such a list would actually be helpful to those evaluating the system by the way. I choose to use iRedMail with my new email setup because it simplified the installation greatly (and was very very similar to my existing setup), and the Pro admin panel is very nice and a huge time saver (though I would like to see a few changes). Even though I'm running a very small email server the cost was worth the time savings to me. With a better understanding of the package choices I'll be better positioned to understand the system choices if I decide to make modifications. The only reason I discovered roundcube didn't use the apt system package was because I went to install the two roundcube plugin packages Debian has and the 'required' package list included roundcube which caught me off guard. With the reasoning for non-apt installation I can make the informed choice of whether to switch to the debian version and what those impacts will be. But to do this I'd need to know not only the reason for roundcube being outside apt but also any potential additional (supporting) packages which aren't using apt.

I believe such a list is a critical piece of support and documentation. I wouldn't be surprised if such a list already exists and I just haven't found it.

Thanks,

Trent

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: Package choices and why outside the package management system

Hi Trent,

It would be better if you can split your questions into many small pieces, it will be easier for me to answer.

hansonte wrote:

I believe such a list is a critical piece of support and documentation. I wouldn't be surprised if such a list already exists and I just haven't found it.

Unfortunately, there's no such list. You're the first person who asks me to explain this situation.

hansonte wrote:

I'm looking for things like why you choose the apache2-mpm-prefork package which is the non-threaded version, I'm not a aware of a reason this would be better, but you've clearly got a reason.

Maybe you prefer apache2-mpm-worker? It's ok, try to convince me.
I'm just a normal man, i make mistake too, sometimes it's stupid mistake. Please correct me if you think i'm wrong. Easy?

hansonte wrote:

Another example would be packages that aren't using the package used by the distribution. Such as in my case the Debian wheezy version of Roundcube. Such choices forgo the package management system and the security updates it brings. I haven't reviewed this one closely but I don't see an obvious reason for that.

This is a special case.

Roundcube, as a web application which mostly used by end user, it's better to keep it up-to-date to get latest features and bug/security fixes, etc.

Debian 7 (wheezy) ships Roundcube-0.7.2. I understand Debian sticks to one special stable release of Roundcube, and provide bug/security fixes/patches for this version. But it would be better to provide new features to end user too.

Another important reason is to make maintaining iRedMail easier. Thinking about configure one component for several Linux/BSD distributions, and each distribution ships a different version. Will it become a nightmare? Sometimes, no. but sometimes, yes.

Roundcube-1.0.x has differrent config file than 0.9.x (and earlier releases), it will be a little hard (actually, unhappy) to maintain code to detect Roundcube version and configure their config files.

Roundcube-1.0.x lets you store custom settings in config file 'config/config.inc.php' and keep default settings in 'config/defaults.inc.php', it's much easier to upgrade Roundcube-1.x to newer releases: untar new release -> copy old config file to new release -> done. With Roundcube-0.x, you have to figure out what settings you modified in 'config/main.inc.php', then update config file in new release.

Although it might sounds pretty bad, but i have to say, sometimes it's not about "principle" (always use packages provided by Linux/BSD vendors), but "easiness/happiness".

Hope it helps.

hansonte wrote:

and the Pro admin panel is very nice and a huge time saver (though I would like to see a few changes)

Please don't hesitate to let me know what you need. Mail me: http://www.iredmail.org/contact.html