MailScanner, CentOS 5 and perl-IO & perl-File-Temp

Julian Field MailScanner at
Sat Apr 11 16:55:53 IST 2009

On 11/4/09 02:24, Julian Field wrote:
> On 11/4/09 01:32, Julian Field wrote:
>> On 11/4/09 01:21, Julian Field wrote:
>>> On 7/4/09 16:31, Kai Schaetzl wrote:
>>>> Julian Field wrote on Sat, 04 Apr 2009 19:52:56 +0100:
>>>>> That sounds ancient. If you check the ChangeLog on I
>>>>> think you will find a whole host of bugs fixed since that version.
>>>> Who says that the important fixes are not in that version? The 
>>>> point about
>>>> enterprise distributions is that you keep a reliable system for a long
>>>> time that also gets security and serious bug fixes over this time.
> The enterprise distributions, in my experience, just upgrade the 
> version of the Perl module used to build the RPM, they don't actually 
> edit the source of the Perl code itself. So these old versions you are 
> seeing really are old versions of the code. Feel free to produce a 
> counter-example, with proof from the RPM file and/or the RedHat 
> changelog.
>>>> What you are doing with your install script is about the same you 
>>>> did 5 or
>>>> more years ago. It may have been necessary back then.
> A lot of people still use old systems running RHEL3 or worse. And then 
> there's all the 5-year old Fedora systems still out there...
>>>> Nowadays the major
>>>> distributions are equipped with decent Perl support and with a slew 
>>>> of the
>>>> most important modules. And most other modules are usually 
>>>> available as
>>>> rpms from an external repository that specializes in that 
>>>> distribution.
>>>> Forcing rpms on top of the existing perl installation and included 
>>>> modules
>>>> is definitely something that one should not do. And it's easily 
>>>> avoidable.
>>> This is only partially true. Quite a few of the modules do not 
>>> "force install" on RHEL5 or CentOS 5 systems. One of the big 
>>> problems is that there are many Perl modules where the Makefile.PL 
>>> tells it to install in the core tree rather than the vendor or site 
>>> trees. If the module attempts to install in the core tree, there is 
>>> no alternative in the RPM built from that to "force install" it. 
>>> This is true of quite a few different Perl modules. So if you build 
>>> from CPAN you never see this. What do rpmforge and the like do about 
>>> this problem?
>>> Examples of this are bignum, File-Temp and IO, though there are 
>>> others too.
>>> You can see them in the big table of modules in the MailScanner RPM 
>>> script in the last column in the lines. This is the 
>>> "FORCE5" parameter where a "yes" makes it do a "force install" on 
>>> RHEL5/CentOS5 systems.
>> Okay, I can answer my own question. He builds them with various 
>> options to the "Makefile.PL" that I didn't know about, and over-rides 
>> the build dirs so they build into the vendor path instead of the core 
>> path.
>> How about I pinch his *.spec file for each of the modules where I 
>> still "force install" on RHEL5/CentOS5 systems and stop doing the 
>> "force install" on those systems?
> I have done this, and have just released 4.76.4 which should not 
> "force install" any modules at all on a RHEL 5 or CentOS 5 system. 
> Hopefully after you have installed that, you should be able to "yum 
> update perl" on your system without any clashes at all.
>> Would you prefer me to do it for all the modules for RHEL4/CentOS4 
>> systems as well, or are you not bothered by that one?
> That would be a fair bigger bit of work, there are a lot of modules to 
> fix. But I'll do it if you think it is worth it.
> Your thoughts please... :)
It should now definitely install cleanly on RHEL5 and CentOS 5 without 
any problems, and without doing a "forced" install of any modules. This 
is with 4.76.6.
It won't force install any modules on any other version either, I just 
haven't had a chance to test it on these and iron out any problems yet. 
That's the next job.

I'm nearly there :) This is taking a hell of a lot of work on the 
installer, but will solve all the upgrade problems once and for all. 
There are interesting things like the fact that RedHat got the module 
path @INC totally wrong in their release of Perl in RHEL 5, with the 
result that a lot of modules simply cannot be over-ridden without doing 
a "forced" install of files to overwrite stuff in their RPM, unless of 
course you mess with @INC at the start of your Perl program (which is 
what I have done) so that the vendor and site-specific directories 
actually get consulted before the core Perl system directories.


Julian Field MEng CITP CEng
Buy the MailScanner book at

MailScanner customisation, or any advanced system administration help?
Contact me at Jules at Jules.FM

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654
PGP public key:

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

More information about the MailScanner mailing list