brotherTwitch has asked for the wisdom of the Perl Monks concerning the following question:

This has got to be a FAQ, but I coud find it nowhere there...

I've been schooling myself on Oracle for purposes of pursuing some light database applications programming Ala perl/cgi, html, and Oracle. (Nothing like job skills, eh? ;^)

As might be expected, I've been having a rather beastly time getting the perl DBI/Oracle DBD code properly installed.

My oracle server is running Oracle 8.6.1 on RH6.1, 2.4 series kernel, with perl 5.006 (I think that version is correct), my webserver (where the cgi code runs) is running RH7 (also with a 2.4 series kernel), and a fairly recent Perl release (whatever was sent down the pipe with the last 'up2date' run).

I had some limited success initially when putting this stuff together - the biggest problem I seem to have had is that when I execute 'perl -MCPAN -e shell' and subsequently 'install Bundle::CPAN' (as directed by ppm) it goes out and attempts to freshen the base perl package (which takes a rather long time and generally fails).

Having gotten past the issue that the DBD::Oracle piece has to be (manually!! no ppm!) installed on the Oracle server (as opposed to the webserver ((man what was I thinking?)) ;) I guess I'm left with two installations of perl that are broken in places (or at least have some broken code installed).

As an aspiring perl programmer this is not the first time I have found myself in a situation like this; generally perl proves so difficult to fix directly that I end up reloading the O/S, or at minimum, something simillarly painfull.

I guess I what I really need to know is: Is there a clean and simple way to back out failed module installs? I've already made several runs at installing various DB* modules as I work out the particulars of this environment; I've broken code, unneccesary modules, and various other by products of experimentation that I need to clean up. Any instruction along these lines would be greatly appreciated.

Oh, and if you happen to have any good pointers for doing database appps with oracle and perl I'd be delighted to hear your suggestions there as well.

May the manifold blessings of Eureka! visit you often-

BrotherTwitch

Replies are listed 'Best First'.
Re: Perl In, Perl Out...
by arturo (Vicar) on Jun 07, 2001 at 19:00 UTC

    Client installation: for anything that needs to talk to the Oracle server (in your case, the webserver).

    • Install the Oracle *CLIENT* libraries and software on the client system. Pro*C and Pro*C++ should be what you need for DBD::Oracle. sqlplus isn't necessary, but it's nice to have for tracking connectivity problems down.
    • make sure ORACLE_HOME and ORACLE_SID are set.
    • install DBD::Oracle
    • enjoy

    As far as backing out failed installs: simply removing the .pm files from the perl module directory tree should work, but if you're using CPAN you can always use the "force" option to install over a broken installation.

    perl -e 'print "How sweet does a rose smell? "; chomp ($n = <STDIN>); +$rose = "smells sweet to degree $n"; *other_name = *rose; print "$oth +er_name\n"'
      Sometimes having these set I still have a problem. What I have to do is run:
      export LD_LIBRARY_PATH=$ORACLE_HOME/lib export ORACLE_USER=username/password@SID
      right before you install the DBD for Oracle. Once you get it installed then you are going to want to add a line in your /etc/ld.so.conf file
      This line will be:
      /full/oracle/home/here/lib
      then save that file and run ldconfig. It will save you tons of headaches in the future.

      --BigJoe

      Learn patience, you must.
      Young PerlMonk, craves Not these things.
      Use the source Luke.
Re: Perl In, Perl Out...
by runrig (Abbot) on Jun 07, 2001 at 18:56 UTC
    Just delete the '*.pm' files that got installed in the library directory. And any files/directories in the 'auto' directory for that module (e.g. for DBI and any DBI::* modules, theres an auto/DBI directory in the same directory as DBI.pm and the top level DBI directory).

    Or just install the modules again.

Re: Perl In, Perl Out...
by chipmunk (Parson) on Jun 08, 2001 at 01:13 UTC
    The very first module you should install with CPAN is the CPAN module:
    install CPAN reload cpan
    This will upgrade the CPAN module to the latest version available, in which the obnoxious bug of downloading an entire perl distribution has been fixed.

    Unfortunately, there is no simple way to uninstall a module. `make uninstall` purports to remove files, but really it does nothing. :( The only way to do it is to track down all the files and remove them manually.

Re: Perl In, Perl Out...
by toma (Vicar) on Jun 07, 2001 at 23:56 UTC
    I like to install a perl that is in a completely different directory than the system perl. I have a script that unpacks the perl distribution, runs configure, and installs the modules such as DBD. I have to be very careful when the script installs the modules that the step
    perl Makefile.PL
    runs the correct perl, so I just give it the full path:
    /home/username/perl5/bin/perl Makefile.PL
    Also, I am careful to use separate directory trees for the perl build and the perl installation. So I compile perl in /home/username/perl5_build. I compile the modules in /home/username/perl5_build/modules.

    I developed this methodology to make my perl builds reproducible and not depend on ppm working properly. I like ppm but I have seen it get confused and trash things too many times. Building everything from source is tedious but I have found it to be worthwhile and rewarding.

    Other advantages of this approach are :

    • I can install a new version of perl in a new directory and try it without losing my old version.
    • When I change to using a different computer my perl environment moves with my home directory.
    • My script documents my build so that someone else can reproduce my system.
    It should work perfectly the first time! - toma