How rude!

VSarkiss on 2005-03-17T15:23:43

At my current client, we're supposed to develop the new data warehouse on Oracle. The problem is that the new hardware for it won't be here for another month.

I realized earlier this week that Oracle offers free development licenses for prototyping, so I grabbed a copy and brought it up on my WinXP box yesterday. The Oracle installer is a slow, nasty, Java application that takes forever, and has an awful UI. But hey, this is just for my own development, so I don't mind playing DBA in a pinch.

After it finished, I was testing connectivity, and I decided to see if DBI would work. Imagine my surprise when I got all kinds of binary incompatibility errors just from typing perl -MDBI -de 1!

Turned out the nasty installer had put a complete copy of perl 5.6.1 under the Oracle tree, and pointed PERL5LIB to it. Which, of course, made my 5.8.4 install puke. They have some system install scripts written in Perl, and apparently decided it was OK to bring the whole thing over rather than seeing if I had perl installed already. Their scripts don't appear to have any XS code either, so it's nothing a use lib or a use v5.6 wouldn't have fixed. After I fixed PATH and PERL5LIB, everything's ran fine.

All I could think of was, "How rude!" If you're going to stomp on my box, at least tell me where....

---

only slightly rude

jmm on 2005-03-17T17:45:53

Installing their own copy of perl is the right decision - they can test their scripts and know that they work on the version of perl that is provided; and be totally indendent of whether your box has perl already installed, or affected if your upgrade, downgrade, or uninstall perl from your box. At a previous employment, we did exactly that - that suite continued to run on a perl4 version for 5 years after perl5 was out and would have failed if its internal scripts had been used in perl5 instead.

It should be only be visible to their own scripts, not exported to your environment, however. Especially if it is just for install scripts, it should not be in the PATH that is needed for application users - it is easy to put a shell script wrapped around such install scripts that sets the private environment as needed and then invoked the perl script.

could have been worse

link on 2005-03-17T20:56:24

A couple of years ago I installed the vantive ( bug tracking ) client on my windows 98 pc. I was instructed to reboot,after doing so windows couldn't find itself and I was dumped into a dos shell as the install had messed up my autoexec.bat and dos couldn't find win.com

Has been worse

htoug on 2005-03-18T08:34:42

I had the misfortune to have to install Oracle in '90 or there abouts. It changed the permission on /dev/null, which had no end of uncomfortable consequences. I dutifully reported it as a serious bug.

A couple of years later I had to update the installation. Imagine my horror when exactly the same overwriting of /dev/null happended (and I had forgotten all about it in the meantime, so it took most of a day to find - again).