On Tue, Jul 7, 2009 at 1:37 PM, Brian Reichert<reich...@numachi.com> wrote: > I have a weird scenario I'm tasked with: > > I've been packaging perl modules as RPMs. I have, to date, been > successful with cpan2rpm to accomplish this: > > http://perl.arix.com/cpan2rpm/ > > Now, my environment has changed. The host I'm now packaging on > runs perl 5.10, but the target Linux host has 5.8.8 installed. > > My packaging generates files that live in /usr/lib/perl5/site_perl/5.10, > but that directory is unknown to the target perl distribution. > > That target distribution is stock Red Hat EL5. It was not complied > with the ability to use sitecustomize.pl, so I can't tweak @INC in > that manner.
This sort of thing is exactly why the experts (schwern, chromatic, et al.) strongly recommend compiling a custom perl for production environments. By compiling your own using a prefix like /opt or /usr/local, you gain total control over which version of perl you are using, as well as the ability to move your application much more easily between different platforms. Also, you pretty much eliminate the problems associated with conflicts between the vendor's packages and your own packages and/or CPAN installs. I've found that building a custom perl .deb package is relatively easy using the checkinstall program. I've actually written a simple shell script that downloads the desired perl tarball, unpacks, configures, and then builds and tests it before using checkinstall to generate the package. In fact at this very moment, I'm about to see if the script will work on an RPM based host as well! -- -- Steve Scaffidi <step...@scaffidi.net> _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
