Credits to you for posting on this topic. I've been interested in how to approach "the
Debian Problem" since I got started using GNU/Linux late last year. I've done a lot of
thinking about this too, but didn't post any write-ups about it yet.
I switch to perl-5.8.0 by such
a simple command as
`swap_perl 5.8.0' which gives me a clean, coherent,
complete environment in which the man dirs and the architecture- or version- dependent modules locations (contents of the
@INC) are all consistent with the perl executable version (release) being used at that time. Doing
`swap_perl 5.6.1' returns me to Debian "Woody" -standard Perl. Tomorrow or next week I can build another Perl at any version level and install it without compromising or clobbering my existing perls.
This system is why the perl scripts I post in write-ups on PM use the she-bang line
that looks like this:
#!/usr/bin/env perl
-- that way I can run any script I create on my system using any perl, without having
to manually edit she-bang lines in every script endlessly.
Update Sat Aug 23 2003 10:12 UTC
On my receipt of a quick question from ybiC I decided to post a little more explanation
here. The system I am describing would not necessarily be incompatible with what ybiC
is describing (which to the extent that I grasp it without rigorously trying out each
step, creates, AFAICT, a fairly "ordinary" /usr/local -based Perl install on Debian).
OTOH what I was suggesting is that some people might want to do this instead
because it does offer some advantages in the long run, and so why invest the time in the
short run?
The crux of my explanation can perhaps be conveyed most efficiently by simply pointing
out where my Perl-5.8.0 is installed. The following listing demonstrates this (and was
quickly created, of course, by using showPerlDirConfig and slightly filtered for compactness):
We are checking configuration of the Perl installed in /opt/perl/bin/5.8.0/perl :
---------------------------------------------------------------------------------
archlib /opt/perl/lib/5.8.0/i386-linux-thread-multi
---------------------------------------------------------------------------------
bin /opt/perl/bin/5.8.0
---------------------------------------------------------------------------------
man1dir /opt/perl/man/5.8.0/man1
---------------------------------------------------------------------------------
man3dir /opt/perl/man/5.8.0/man3
---------------------------------------------------------------------------------
privlib /opt/perl/lib/5.8.0
---------------------------------------------------------------------------------
sitearch /opt/perl/lib/site_perl/5.8.0/i386-linux-thread-multi
---------------------------------------------------------------------------------
sitebin /opt/perl/bin/5.8.0
---------------------------------------------------------------------------------
sitelib /opt/perl/lib/site_perl/5.8.0
---------------------------------------------------------------------------------
vendorarch
---------------------------------------------------------------------------------
vendorbin
---------------------------------------------------------------------------------
vendorlib
---------------------------------------------------------------------------------
Note that the structure under prefix /opt is different, unconventional vis a vis
what is usually described. This is achieved at build time through arguments to Perl's
./Configure. Everything here is highly versioned, allowing us to keep adding more
releases/distros of Perl without interference with previous ones.
Lastly in this update, allow me to emphasize that I hope no readers will mistake my
intended meaning and think that I am finding fault with ybiC's writeup. His work
definitely shows knowledgeability and competence with Debian policy and insight into
what might make Debian more fun to work with / play on. And after all, TMTOWTDI.
Now back to the original reply
The investment in time in getting this set up was considerable because there are a few
inconsistencies in the article cited, and some experimentation was involved. Now that
it is running smoothly, however, I am very happy that I did it this way and didn't take
a less far-sighted approach. There are easier ways of running multiple perls, all of
which end up requiring more "manual" futzing (that's a very special technical term) and
back-tracing when something doesn't work like you supposed it would.
It's like the difference between the approach of the architect and the approach of the
mechanic that was once discussed on a node here at PM. An architect-type sysadmin takes
a long view and more abstractly ponders questions of scalability, maintainability etc.
A mechanic-type sysadmin displays great skill and knowledge in putting out little fires
and dealing with myriad small breakdowns that may occur. I am trying to re-make myself
into more of the "architect-type" Perl administrator.
Note:
The tpj article mentioned was published since the Journal has left
SysAdmin magazine and is therefore not archived at their site. It has only been
seen by subscribers to the new E-format (online) Journal.
Soren/Intrepid
--
use PerlMonk::Tye qw(:wisely);