Packaging a new version of a core perl module

[Matt Grimm]

Thanks for the suggestions, Tim.

I was able to get this working by modifying the spec file to install the code into site_perl and skip the installation of man files (since they all go into /usr/share/man). 

In response to Todd's concerns about vendor_perl taking precedence over site_perl, that's not the behavior of my system. The site_perl dirs come first in @INC, so my custom threads-1.81 RPM gets priority over the core version:


mock-chroot> rpm -q --queryformat="%{VERSION}" perl; echo
5.8.8
mock-chroot> perl -Mthreads -e 'print $threads::VERSION'; echo
1.81
mock-chroot> perl -e 'print join ", ", @INC'; echo
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi, /usr/lib/perl5/site_perl/5.8.8, /usr/lib/perl5/site_perl, /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi, /usr/lib/perl5/vendor_perl/5.8.8, /usr/lib/perl5/vendor_perl, /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi, /usr/lib/perl5/5.8.8, .
mock-chroot> 


m.


-----Original Message-----
From: rpm-list-bounces at lists.rpm.org [mailto:rpm-list-bounces at lists.rpm.org] On Behalf Of Tim Mooney
Sent: Wednesday, November 17, 2010 3:08 PM
To: General discussion about the RPM package manager
Subject: Re: Packaging a new version of a core perl module

In regard to: Packaging a new version of a core perl module, Matt Grimm...:

> How does one go about packaging an RPM for a newer version of a core
> perl module? The core modules are all included in the perl RPM, so they
> can't simply be replaced as with non-core modules. If the new files will
> conflict with the older ones, I'm not sure how to work around that.

The short answer is that there's no easy way to work around the issue.
We've seen it too.

About all you can do is use --replacefiles when you install the RPM, to
replace the files in the original package.

The down-side is that if you use some kind of automatic update facility
(like Red Hat NetWork) for vendor packages, then unless you take special
precautions, the next time your vendor releases an updated version of
perl, it could overwrite your version.  Last In "wins".

Your only other option is to override how the perl module installs itself
at package build time, so that it goes into site_perl or some other directory, 
and then make certain that any modules that "use foo" get your version
first, rather than the older version that's part of core perl.  Also not
easy.

Tim
-- 
Tim Mooney                                  mooney at dogbert.cc.ndsu.NoDak.edu
Enterprise Computing & Infrastructure       701-231-1076 (Voice)
Room 242-J6, IACC Building                  701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
Rpm-list mailing list
Rpm-list at lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-list