We've done this at work. Well, someone else did it, I'm just passing it on ;-)

Consider:

/share/linux86-64/bin
/share/linux86/bin
/share/linuxia64/bin
/share/linuxppc64/bin
/share/hprisc/bin
/share/hpia64/bin
/share/sunsparc/bin
/share/sun86-64/bin
/share/aix/bin
# etc.
/share/common/perl/lib
[download]

Now, if, when you compile perl, you tell it the appropriate bin directory and the common perl lib directory, for where to put executables and libraries, respectively, you'll have a single share with everything you need. I assume you don't need all of the above, but you may.

The next requirement for this is that anyone on, say, HP/ia64 (Itanium) will have to add the correct bin directory to their $PATH, e.g., PATH=/share/hpia64/bin:$PATH. This is so that the new perl is found first.

Finally, your xyz.pl script would have to start like this:

#!/bin/sh
eval 'exec perl -S "$0" "$@"'
    if 0; # this line keeps it from being seen by perl.
[download]

This will load the shell, which will evaluate the string, which will cause it to exec (replace itself with) perl with the name of the script and any parameters passed along. Perl will load the script, ignore the first line (the #! line doesn't have "perl" in it), start executing with the second, see the eval over two lines, see the if 0, and the compiler should optimise it away. And then it will merrily go on to the rest of your code.

Now, all this said, when you compile perl, you should have the opportunity to hard-code some extra paths into @INC. My recommendation? Do so. Hard-code in a location for your OWN modules (not the ones you're installing from CPAN). For example, /share/common/perl/locallib. And then you can put your modules here. I say this largely because I'm of the opinion that every(*) perl script that is intended to last more than the day it's coded on should look like this:

#!/bin/sh
eval 'exec perl -S "$0" "$@"'
    if 0; # this line keeps it from being seen by perl.
use lib ...; # if necessary.
use My::App; # or whatever it's called.
my $app = My::App->new();
$app->parse_args(@ARGV); # passing in @ARGV is recommended but not req
+uired
exit $app->run();
[download]

Basically, load the module that has the real code, create the app object, tell the object to parse the arguments, and then tell the object to run, exiting with whatever return code it returns. The reason for this is simple: it makes it easier to write unit tests for your code. It also makes it easier to embed your app within another one, but that's the same as writing unit tests, since unit tests will generally embed the app within the .t file (by doing the same as the above).

(*) Ok, there are other exceptions, too, but it's a general rule for me.

BTW - this is an NFS share with hundreds(!!) of developers using it. Our build environment is built in perl (using make underneath), so even our C/C++ or Java devs will use perl, without knowing it. The share also has the Windows perl on it, and is shared via samba. While I'm sure that the machine has Gigabit networking, I don't think caching has been an issue. By default NFS (and I assume samba) already does do some caching anyway.