David Bouw wrote: > I don't know if I will run in any problems (libs etc) if I try to install a > new PERL package. (My experience with PERL is very limited, I solve most of > my problems with PHP scripts).
One way of dealing with this is to segregate your software. I'm building a complex qpsmtpd infrastructure (not just the filtering, but database'd logs, quarantine viewers, metrics etc), which needs a lot of stuff other than just qpsmtpd and my plugins. The way I'm doing it is to install _all_ of the software it needs (including Perl (uprev from standard provisioning), all non-core perl modules, postgresql, spamassassin, clamav etc) in a directory hierarchy entirely separate from the "standard system" install. Done by setting the "PREFIX" of _all_ software I install somewhere else during config/build/install. This means that qpsmtpd is only dependent on the Perl modules (and other stuff) explicitly installed for it. Support can reinstall/upgrade anything in the "standard box" without affecting qpsmtpd. And vice-versa. Two separate Perl installations (different versions). System's perl (/usr/bin/perl) isn't used by qpsmtpd. Further, I can install the _complete_ operational package on other machines with nothing more than an rsync, adjusting the system /etc/init.d|rcN.d and crontabs, and a few minor tweaks on the qpsmtpd config (such as config/me). I'm running it on 5 machines, not all quite the same OS rev level (currently Sparc/Solaris, will be Linux later), so the replicability is particularly nice.
