[rt-users] Install on CentOS, best current instructions

Jeffrey Fearn jfearn at redhat.com
Sun Aug 8 21:27:08 EDT 2010

Howard Jones wrote:
>  On 06/08/2010 19:09, Jerrad Pierce wrote:
>> Install from source, with a non-system perl.
> Why non-system perl, Jerrad? I've never had a problem with it (that I 
> know of), but have I just been lucky?
> My only RPM-related problem is having to reinstall a current version of 
> Sys::Syslog after every yum update (anyone know why that happens?)

You are over writing files supplied by the perl package.

$ rpm -q --whatprovides 'perl(Sys::Syslog)'

When the perl package gets updated, RPM compares the checksums of the 
installed files to those in the new package, detects the checksums don't 
match, and installs the files from the new package over the existing ones.

This is correct behavior and the only sane way a package manager can 

Furthermore if you run a verify over your file system errors will be 
reported since the files installed do not match the checksums from the 
RPM, so you've made your system unverifiable. Probably not a great 
tragedy, but something you should avoid unless you have a very 
persuasive argument.

It's trivial to avoid this if you use RPM. You can either roll your own 
spec file or use cpanspec to do the heavy lifting for you. I use cpanspec.

1: install the cpanspec package (on your development box eh)

2: cpanspec Sys::Syslog

3: edit perl-Sys-Syslog.spec as below

4: rpmbuild -ba  --define "_sourcedir `pwd`" --define "_builddir `pwd`" 
--define "_srcrpmdir `pwd`" --define "_rpmdir `pwd`" perl-Sys-Syslog.spec

5: install the RPM where required, or setup a yum repo

All the --defines aren't strictly required, but it forces rpmbuild to 
use the current directory and that's generally where I want the RPMs to 
end up.

### spec file edits ###

%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS" 


%doc Changes README README.win32
# change man path

### end spec file edits ###

Since vendor is searched before core, the new module gets found first. 
Since the files are on a different path to the ones in the perl package 
they won't get affected when perl updates.

If you are having a clash in vendor, use site instead, which is even 
earlier in the perl path.


Cheers, Jeff.

Jeff Fearn <jfearn at redhat.com>
Software Engineer
Engineering Operations
Red Hat, Inc
Freedom ... courage ... Commitment ... ACCOUNTABILITY

More information about the rt-users mailing list