On Tue, 2009-07-07 at 13:37 -0400, Brian Reichert wrote: > I've been packaging perl modules as RPMs.[...] 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. >
I can think of a couple of things: (a relatively hacky way): create a small RPM that contains just a symlink from /usr/lib/perl5/site_perl/5.10 to /usr/lib/perl5/site_perl/5.8 . Make your cpan2rpm-style rpm's --require= on that module. (suggesting what you already said you tried, but with more detail because you didn't say where it failed): The command "cpan2rpm --make-maker='INSTALLSITELIB=/usr/lib/perl5/site_perl/5.8'" seems to work for me for Perl modules built with MakeMaker, but not Module::Build. (just as the docs warn.) Perhaps if you need to use cpan2rpm with Module::Build based modules, you could use the --prologue=install: command line argument to move the 5.10 directory to 5.8 before building the binary RPM. Or you could use the --spec-only flag to build a .spec file to munge a bit (s#%{__perl} Build.PL#& --config installsitelib=/usr/lib/perl5/site_perl/5.8#) and then do the final rpmbuild step by hand. Or perhaps patch cpan2rpm to add support for Module::Build command line arguments and send the changes back to the developer. (the docs imply that the developer wants to add args to Module::Build->new() but what would be really helpful is to add args to the "perl Build.PL" and "./Build" command lines just like MakeMaker) (a hammer to squash an ant way): You could get a copy of your target environment to build on. Virtual Machines are cheap to setup copy around and destroy. I usually get uncomfortable when a vendor isn't testing the product I'm buying on the platform I'm deploying on. (what they use as their primary development platform is another matter.) (the "me too" way): In some situations, the option others have suggested of supplying your own perl and not depending on the system perl is a good one. Stability is a good thing, and you probably don't want your code to suddenly fail when an automated security patch changes the perl install in some subtle way. The question is whether you are delivering them a perl solution or a solution that happens to be developed in perl. If the client doesn't care if its in perl or is interacting with it as a perl product, it is a candidate for building your own perl and deploying a complete turnkey solution. If its a piece of their larger perl solution, then you have to work with what they're using. _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm