in reply to [perl|DBI] packaging tool with DBI and DBD::Oracle

G'day charithd,

Having control over which versions of modules your clients are using can actually be a boon (rather than an onerous responsibility). It can save a lot headaches with version incompatibility between software on different machines. It also removes your reliance on the client doing the right thing which, in my experience, is fraught with problems.

Having said that, neither DBI nor DBD::Oracle are pure Perl modules: both require compilation. So, the task is somewhat more complicated than just copying some *.pm files to certain locations.

What you possibly could do would be to distribute the source for those modules and provide an installation shell script which can be run on each machine that requires it. This is something I've done in the past with many modules and, in general, it's worked well.

Installation of DBI is fairly straigtforward and should be easy to script. It's been quite some time since I installed DBD::Oracle, so I can't really comment on that (although I do seem to remember doing something along these lines with this module many years ago): you've probably got current knowledge and a much better idea of what's involved that I do.

-- Ken

Replies are listed 'Best First'.
Re^2: [perl|DBI] packaging tool with DBI and DBD::Oracle
by charithd (Acolyte) on Mar 28, 2014 at 11:26 UTC
    Good day to you kcott and Thank you very much you are saying that best way is convince the client to install modules right :)
[reply]

      IMHO at least the DBD::Oracle part. You need the right ORACLE_HOME, you need the right libraries linked. And as soon as the DB admin decides to upgrade his ORACLE installation he has to think about client code too. So, I think putting the DBD::Oracle installation into the responsibility of the DB admin is not a bad idea. And working down 10 lines of installation instruction is a little step compared to an ORACLE upgrade. ;-)

      McA

[reply]

      Just to ensure we're on the same page with this, distributing pre-compiled binaries probably isn't a viable solution. Instead, I'm suggesting you distribute the versions of the module source that you've tested your tool with, e.g. DBI-1.631.tar.gz and DBD-Oracle-1.70.tar.gz (the latest versions at the time of writing). In this way, you retain control over the versions of these modules.

      Then the client can install these as needed. You can retain further control over how the installation is performed by supplying an installation script. The guts of this script would probably be along these lines (which is just off the top of my head): 

      tar zxvf Module-version.tar.gz > Module-version.INSTALL 2>&1
cd Module-version
perl Makefile.PL
make
make test
make install

      [download]

      This way, you control what is installed and how. You don't need to become physically involved with the installations yourself, e.g. getting access to machines, waiting for compilations & tests to complete, and so on. The extent of that involvement, if you did it youself, would depend on your relationship with your client (which you haven't told us about): on-site or remote access; level of privileges, etc.

      The client does the work but, as that only involves running a script you've provided, would probably make them more inclined to do so. It may even appear that you've done additional work for them which would likely be received positively. Again, all this will depend on your relationship with your client, so I'm guessing somewhat here.

      -- Ken

[reply]
[d/l]
[select]
        McA and kcott, I'm so thankful for your expertise opinions.
[reply]

In Section Seekers of Perl Wisdom