[Pdx-pm] [csieh at fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl]

J. Shirley jshirley at gmail.com
Tue Aug 26 19:37:28 PDT 2008


On Tue, Aug 26, 2008 at 4:40 PM, Keith Lofstrom <keithl at kl-ic.com> wrote:
> On Tue, Aug 26, 2008 at 10:27 AM, Keith Lofstrom <keithl at kl-ic.com> wrote:
>
>> I spoke too soon.  Sigh, no distro support on this one.  OK,
>> for the complete Perl noob, how does one go about maintaining
>> two versions of Perl on a machine, one for "system" and one
>> for everything else including serving web pages?
>>
>> Understandable, updated, robust and secure is good.  I fear
>> the only option is a large learning and maintenance burden.
>
> On Tue, Aug 26, 2008 at 10:46:33AM -0700, J. Shirley wrote:
>
>> I would highly recommend looking at local::lib,
> ...
>> to build it in /opt/perl/perl-5.10
> ...
>
> Good stuff!  Everyone agrees with maintaining 2+ Perls, and I
> now understand the wisdom of that.   I'm not so convinced by
> the env approach, or using /opt for the alternate Perl.  Others
> point to writing the scripts with #!/usr/local/bin/perl .   Since I
> am not a developer, merely a user crawling through no-man's-land
> between the Red Hat and Perl trenches, I hope I can come up with
> something that is easy to maintain and understand without getting
> my butt shot off by third-party cybersociopaths as I crawl along.
>
> Based on what has been posted so far, my inclination is to keep it
> simple and use the hard-path /usr/local/bin/perl approach for all
> my local and CGI scripts.  Then I figure out some way to keep the
> modules current and secure, since I will now be dating outside
> my distro and its automated update process.  If there are any
> books or articles or documentation with cookbook-ish formulas
> for doing this mostly correctly, I would welcome some pointers.
> I am in awe of the adept chainsaw juggling practiced by the
> wizards of Perl, but it is not something I want to try at home.
>
> Keith
>

Just to clear up a few points about my position with env and /opt
(before the thread fades away), if you know you are only going to deal
with two perl binaries and that is it the usage of env doesn't really
get you anything.  I find it easier to err on the side of
expandability, and set things up in a way that gets me the most
flexibility in the longer term, but I also work in environments that
typically require different environments.

The reason for putting custom perl builds in /opt is that I view it as
an add-on dependency for whatever application.  This method fits in
with the UNIX idea of /opt, and here's a quote as to why I came to
that conclusion:

Purpose

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a
separate /opt/<package> or /opt/<provider> directory tree, where
<package> is a name that describes the software package and <provider>
is the provider's LANANA registered name.

__END__

So, the way that I see it is that shoving everything in an
/opt/{package} dir is an easier way of figuring out exactly where my
applications dependencies are.  It does require a bit more manual
tweaking of the environment, but I find manually tweaking the
environment is well worth it in these cases.  It also means that you
can just tar up an entire directory, and send it to production hosts
and not have to deal with CPAN installing different versions, etc.  If
you scatter files in /usr/local/bin and /usr/local/lib/perl it gets a
bit harder to do that.

I am very curious how the various cpantesters setup their various
perls for smoking, though.

-J


More information about the Pdx-pm-list mailing list