Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re: Install parallel Perl on Debian

by Intrepid (Deacon)
on Aug 23, 2003 at 05:37 UTC ( [id://286009]=note: print w/replies, xml ) Need Help??

in reply to Install parallel Perl on Debian

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.

There's an excellent article about "Juggling Perl Versions" in the Jan 2003 issue of The Perl Journal that deals with the same motivations which you introduced here. This article, authored by Matt Persico, has information about creating a system whereby an administrator can make an unlimited number of Perl versions available to users without compromising such things as Debian's system dependencies.

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

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.

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.


use PerlMonk::Tye qw(:wisely);

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://286009]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2024-07-25 19:04 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.