If you can live with the versions of the modules that come with the
system's package management, I'd go with that — it's usually the
easiest way. If you need/want bleeding edge versions which
in turn might require bleeding edge versions of other modules already
installed with the system, there's the potential risk of destabilizing
system tools that rely on the specific Perl that's originally shipped
with the system, in case you simply install those newer versions over the
existing ones... (installing your own stuff (with all its incompatible dependencies) into a separate directory is fine, though).
In such cases, I usually compile/install my own Perl under /usr/local,
so I can mess with it at free will, without interfering with the system Perl.
You'd then install modules via the cpan shell. And use lib ... isn't
required in this case, because the perl binary under /usr/local
already knows where to look for its modules...
| [reply]
[d/l]
[select] |
Not much more to add, but chiming in with a hearty "seconded". It's much safer to have your own separate "application" perl (which can be owned by a non-privileged user if you so desire) and don't touch the OS' copy.
You'll be more than glad you took the 15-20 minutes it takes to build /usr/local/perl-5.10.0 when you realize after updating things that the package manager would have rolled you back to Foo-0.31 despite your having upgraded to Foo-0.42 and you've saved at least that much time not having to diagnose that (to say nothing of the next n times something similar is going to happen; or of the flexibility you get by being able to move to 5.10.1 6 months before your OS finally gets 5.8.9).
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply]
[d/l]
[select] |
The latter, since it works both where you have root and where you don't. This way, if you ever have to re-host your site elsewhere, you won't need to revise every single CGI script.
In general, the traditional practice of "avoid using root whenever you can" is a good one to follow; root access is for handling situations that can't be managed any other way. As root, you can always fix the problems created by non-root users - but the reverse is definitely not true.
--
"Language shapes the way we think, and determines what we can think about."
-- B. L. Whorf
| [reply] |
It depends. If you ever want to install multiple versions of your app with different modules on this box, installing as a specific user is better. If not, installing as root is fine on a box that is dedicated to running this application. | [reply] |
/me nods...
Very well, then.
My instincts are confirmed.
I shall proceed as I would with any local-hosting arrangement, “even though I own the box,” because I always want to be sure that no unforseen “yummy thing” will torpedo something down the line ... and that what I may do likewise will not torpedo any important system tool. “Just keep ’em in separate oceans.”
For the curious (and for comments, please, by anyone), the procedure by which I do this is summarized as follows:
- As root, set up a non-privileged userid and associated group, “for the purpose of Perl maintenance.” This user is not one that is ever used by any Apache CGI-session, nor by any other regular software on the system.
-
Create a suitable directory in /usr/local and use chown to this user and group, giving the directory full-access only to that user; read-execute to everyone else. Let's say it's called /usr/local/share/perl ...
-
Log on as that user and run cpan. Do not accept the “convenient” initial offer to set up everything for you. Even so, you can accept most of the options, except for these:
-
make_install_arg [SITEPREFIX=/usr/local/share/perl]
-
makepl_arg [INSTALL_BASE=/usr/local/share/perl]
-
mbuild_install_arg [--site-prefix /usr/local/share/perl]
-
mbuildpl_arg [--install-base /usr/local/share/perl]
You will observe that I consciously set INSTALL_BASE= not PREFIX=.
-
From any user(s) which will be running Perl code e.g. for testing purposes, put the following statement in your .bashrc file, which is executed at startup:
Create a setup-perl file in your local home (non-executable) containing:
PERL5LIB=/usr/local/share/perl
export PERL5LIB=/usr/local/share/perl/lib/perl5.
When you log on, you can say source ./setup-perl to arrange for Perl to automatically look in this location when you run things.
-
I have had problems in the past using .bashrc files for this purpose, although this was in shared-host setups which ran CGI scripts under my userid.
So, do what works best for you.
-
The
struck out code above was incorrect: it caused a symptom whereby “when I updated Perl modules (including CPAN), the updates never became visible.” Furthermore, the export clause must be used so that the environment-variable setting is visible. (Whups!!) You can confirm that all is well by examining the output of perl -V, noting the upper-case “V.”
-
When you write programs, e.g. for the web-site, you'll need to include a use lib statement that expressly points to /usr/local/share/perl. Good web code should be run in “taint mode” and should never rely upon environment variables to cause it to “do the right thing.”
The idea is to make sure that these apps always look in just the right places, and that nothing you can do, oh 733T H4X00R, can make it do otherwise.
| [reply]
[d/l]
[select] |
On my Debian box i install most modules with apt-get (Debian package management). Those modules i can't get as a Debian package, i install in a separate directory via cpan shell. | [reply] |