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

[Julian Field]

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 search.cpan.org 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 
>>> install.sh 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.


Jules

-- 
Julian Field MEng CITP CEng
www.MailScanner.info
Buy the MailScanner book at www.MailScanner.info/store

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: http://www.jules.fm/julesfm.asc


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