MailScanner, CentOS 5 and perl-IO & perl-File-Temp
Julian Field
MailScanner at ecs.soton.ac.uk
Sat Apr 11 02:24:28 IST 2009
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... :)
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.
More information about the MailScanner
mailing list