This may be slightly off-topic (as I'm not really addressing the question about cpan-shell syntax problems), and I may be running the risk of starting a flame war, sorry, but, speaking as a Developer (and former SysAdmin): waiting on RedHat to distribute RPMs (a practice which is advised and necessary for the system-Perl) is a <i><u>horrible</u></i> way to manage Perl modules that are depended on by non-trivial applications.<br>
<br>I'm stuck in a RedHat environment and would never rely on them to get it right for any of the critical systems I work on at my job if it could possibly be avoided... RedHat's track record with Perl module maintenance is not great (and this criticism isn't limited to RedHat: Apple had broken system Perl libraries for many many months in 2008 also, and I'm positively sure there are vendors with this problem).<br>
<br>If Perl is important to you and your job, build it yourself from source!<br><br>As a "best practice" for managing Perl and Perl modules here's what I do (your mileage may vary):<br><ol><li>Compile and install a custom Perl (or multiple Perl versions) using a non-root account, perhaps under /usr/local or /opt. You can use symlinks to simplify the paths for these; and symlinks have the added advantage of flexibility... i.e. upgrades are simple. E.g. /opt/perl -> /opt/perl-5.10.1/ , makes an eventual update to 5.12 trivial both to test and to implement with no changes required to consuming code simply by changing the appropriate symlinks. [Importantly, this way you can be sure that you aren't going to break the system Perl install by upgrading modules, which should put your SAs at ease. My advice: NEVER MESS WITH THE SYSTEM PERL, AND NEVER RELY ON IT FOR ALL BUT THE MOST TRIVIAL (simple one-off script) CASES! Sorry for shouting: I've learned the hard way that this is a recipe for pure frustration and pain...]<br>
</li><li>Update your path: e.g. PATH=/opt/perl/bin:$PATH if you use bash... you can just stick this in your .bashrc.<br></li><li>To address firewall restrictions in a corporate server environment that might make contacting a public CPAN mirror impossible, create your own mini-CPAN bundle to act as a local CPAN mirror on your secure network (or a local filesystem if that's not possible). This archive adds some maintenance overhead (you'll need to update it occasionally), but for any non-trivial installation base it is absolutely fantastic (and surprisingly easy to do)! See CPAN::Mini.<br>
</li><li>Configure your CPAN shell to point to the URL of your mini-CPAN (any of file://, http://, or ftp:// are appropriate depending on how it is accessible). I find it convenient to store the mini-CPAN archive on a webserver and create a symlink under htdocs so that this archive is available on the internal network via http without having to get a firewall exception everytime you need to install a module from a public mirror... but you'll probably need to have a talk with your security team before you get the go-ahead. There's an additional advantage here in that if you are creating standard Perl packaged modules in your organization, they can be 'injected' into your private mini-CPAN mirror for simple automated distribution via the CPAN shell to any end users who can access the URL of your mini-CPAN. Using sudo should not be required to install modules for Perls that have been installed by a non-privileged account: so, to install a module just issue the command 'cpan -i Some::Module' for any system who's CPAN shell is configured to point to this URL.<br>
</li><li>For 'repeatable server builds' I've found it much easier to use a shared file-system (prefer a snap-mirrored NAS for HA reliability, but NFS, or SAMBA are possible too). Build the Perls there and create symlinks on each host according to any platform specific details: e.g. /opt/perl -> [ /opt/NAS/perl-5.10.1, /opt/NAS/perl-5.10.1_x64 ]. So, now, (although you have to compile and install the same module for each individual Perl build) you can manage all the modules in one central location for all systems that have this mount... which could potentially be a very large installation base. This way the 'repeatable' part of any server build is as simple as adding a line to fstab so that the new device is mounted at boot and an appropriate symlink is created for each new host.<br>
</li></ol><br>There's a small amount of overhead with this approach (not as much as you think though, esp. compared to the alternatives), but it <u><i>scales well</i></u> which is very important if you depend on a Perl infrastructure for applications (as opposed to simpler Perl use by the system-OS or Admins).<br>
<br>For further reading along these lines there's some great information that Schwern put together here: <a href="http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices">http://www.perlfoundation.org/perl5/index.cgi?perl_best_admin_practices</a><br>
<br><br>Hope that helps,<br>m<br><br><br><div class="gmail_quote">On Fri, Apr 9, 2010 at 1:11 PM, Tim McDaniel <span dir="ltr"><<a href="mailto:tmcd@panix.com">tmcd@panix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Fri, 9 Apr 2010, Jonathan Scott Duff <<a href="mailto:duff@pobox.com" target="_blank">duff@pobox.com</a>> wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
$ PERL_MM_USE_DEFAULT=1 cpan Bundle::CPAN<br>
</blockquote>
...<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
That's meant to be run from the command line using the "cpan"<div class="im"><br>
command which doesn't take subcommands. So cpan Bundle::CPAN from<br>
the command line will install Bundle::CPAN.<br>
</div></blockquote>
<br>
Thank you for the explanation.<div><div></div><div class="h5"><br>
<br>
-- <br>
Tim McDaniel, <a href="mailto:tmcd@panix.com" target="_blank">tmcd@panix.com</a><br>
_______________________________________________<br>
Austin mailing list<br>
<a href="mailto:Austin@pm.org" target="_blank">Austin@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/austin" target="_blank">http://mail.pm.org/mailman/listinfo/austin</a><br>
</div></div></blockquote></div><br>