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
