The recent node Re: putting perl and modules in your source code repository describes how I build a custom Perl distribution that's distributed with our product.

To defeat the lack of relocatability of perl 5.8.x, mentioned by almut, I ask the user to set an environment variable (YOUR_PRODUCT_HOME, say) and unpack our perl distribution in a well-known sub-directory underneath $YOUR_PRODUCT_HOME. With that done, our custom perl is invoked via a shell wrapper, for example for perl 5.8.6 on solaris the shell wrapper is:

#!/bin/sh
if [ -z "$YOUR_PRODUCT_HOME" ]; then
   echo "error: YOUR_PRODUCT_HOME environment variable is not set." 1>
+&2
   exit 1
fi
$YOUR_PRODUCT_HOME/perl/bin/perl -I"$YOUR_PRODUCT_HOME/perl/lib/5.8.6/
+sun4-solaris" -I"$YOUR_PRODUCT_HOME/perl/lib/5.8.6" -I"$YOUR_PRODUCT_
+HOME/perl/lib/site_perl/5.8.6/sun4-solaris" -I"$YOUR_PRODUCT_HOME/per
+l/lib/site_perl/5.8.6" -I"$YOUR_PRODUCT_HOME/perl/lib/site_perl" "$@"
[download]

In our next release, I'll upgrade perl to 5.10.x and look forward to eliminating the ugly shell wrapper by taking advantage of its relocation capabilities.

Update: Warning: Note that the shell wrapper above is just a dirty hack that works for me in my environment where the customer just uses the distributed perl as is, and does not install any new modules, for example; it is not a 100% sound relocatable Perl. For that, you'll need perl 5.10.x. To relocate perl 5.8.x more soundly, you might further edit Config.pm and study in detail how perl 5.10.x does it (IIRC, ActiveState has done a relocatable Unix perl 5.8.x for some platforms).