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)’
perl-5.8.8-32.el5_5.1
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
operate.
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
%build
add INSTALLVENDORMAN3DIR
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=“$RPM_OPT_FLAGS”
INSTALLVENDORMAN3DIR=/usr/local/share/man/man3
…
%files
%defattr(-,root,root,-)
%doc Changes README README.win32
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/Sys*
change man path
/usr/local/share/man/man3/*
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.
Easy!
Cheers, Jeff.
Jeff Fearn jfearn@redhat.com
Software Engineer
Engineering Operations
Red Hat, Inc
Freedom … courage … Commitment … ACCOUNTABILITY
