"I understand why I need to do this if there are binaries or C libraries that need to be linked with. But why is this needed for straight scripts?"

'Straight scripts' may use version dependent features, for example. A 'straight script' (I usually call them 'programs', by the way) that works correctly in Perl 5.10 may easily use features that are unknown in Perl 5.6.1.

"Believe it or not, but I actually am running out of diskspace."

Disk space is very cheap (I just bought a tera-byte for my home system early this year for $110US; the price is still falling). You need to explain to your Boss that keeping additional versions of the Perl Development Environment around requires additional resources; and that is why you put in for the additional hardware.

"Plus the hassle of having to install multiple times."

So why are you keeping multiple Perl environments around? "Reason: always want to create old scripts running...."

This is called having a Regression Test Bed. The test-bed that is used to verify that your Latest and Greatest Change Fix didn't break anything. If you screw around with your test-bed, by getting rid of duplication and "saving space", that safety net goes out the window. If your test-bed does not look EXACTLY like the installation environment in the field, then you can not draw a valid inference that your change didn't break anything else. You are guessing/hoping that there is nothing broken, but you can't be certain.

"When is it safe to put something like install/lib/5.8.5 on the PERL5LIB path for a perl 5.10.x script? "

It all depends. Do you want to guess about the correctness of your Perl 5.10.x program? Or do you want to be able to tell your Manager that you *know* that the program change hasn't broken anything?

I suspect that a better approach here would be to segregate each different Perl version onto a separate physical machine. That way you get two things clear from the onset -- you can't clobber one version with another by accident; and you eliminate the temptation to 'fix' the installation by consolidating stuff to save space.

These don't have to be big powerful machines, by the way. I once ran a QA/Regression lab on two dozen old Toshiba P-II and P-III lap-tops. They weren't the fast thing on the planet, but they could run the entire regression suite in just over 19 hours. The QA lab was the last stop in the trickle-down chain for hardware. (The Bosses get new laptops; the Tech Lead gets one of the bosses old laptops; I get the TL's old laptop; the Lab get my old machine. So the Lab gets a hardware refresh every 12-18 months.)

What every you do, keep in mind the reason that you have multiple Perl installations. Breaking a Regression Test-Bed is not something you want to do with out a long hard examination of the consequences, both for the company and for your own credibility.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.