Once again into the breach. The release of Ubuntu 10.04 is at hand. I’ve been playing with “Lucid” for a couple of months now but since we’re in beta2 with the release candidate soon to follow, I thought I would really sit down and get my normal app stack working including TOra. All in all the instructions are mostly the same as last time around, with a couple of new improvements, caveats and quid pro quo.

Environment

This one is being written using the 32 bit version of everything. I tend to use my laptop as a testbed and I have not upgraded any 64 bit machines as of yet. The instructions will be the same, you just need to make some environmental changes to get it working with 64 bit systems. I’ll try to update the blog when I do it myself next month, or check my previous guides and extrapolate as necessary.

Get the packages

First off we’ll create new directories for the packages and get the sources. Ubuntu 10.04 is using TOra 2.1.1. If you want the full list of changes in this version then you are out of luck, you can check the NEWS file on the TOra svn site which states only “lots of notes missing for 2.x series”.


mkdir -p /path/to/deb/source/
cd /path/to/deb/source/
apt-get source tora

Now get the Oracle packages. Get them from the Oracle site. Since there’s a new version of the oracle client I am using the lastest and greatest.

  • oracle-instantclient11.2-basiclite-11.2.0.1.0-1.i386.rpm
  • oracle-instantclient11.2-devel-11.2.0.1.0-1.i386.rpm
  • oracle-instantclient11.2-sqlplus-11.2.0.1.0-1.i386.rpm

Install the prerequisites and development libraries

Next we’ll want to install the build dependencies via apt. To do this, run the following simple command.


sudo apt-get build-dep tora

Now we’ll get all the other build tools and libraries that we’ll need for this to work. This list is exactly the same as last time.


sudo apt-get install libqt3-mt-dev libqt3-compat-headers libqscintilla-dev build-essential g++ gcc autoconf automake flex zlib1g-dev docbook-xsl debhelper alien libaio1 dpatch fakeroot xsltproc texi2html texinfo libqt3-mt-psql libqt3-mt-odbc config-package-dev cmake qt4-dev-tools

Next install the Oracle clients. In the directory where you downloaded them run the following to convert and install the packages in one fell swoop.


cd /path/to/oracle/rpms
sudo alien -i *386.rpm

Environment Variables

Now that we have all the bits we need, we set up the build environment. First we set up the oracle home environment and library path.


export ORACLE_HOME="/usr/lib/oracle/11.2/client"
export LD_LIBRARY_PATH="${ORACLE_HOME}/lib"
export TNS_ADMIN="${ORACLE_HOME}"

As before you’ll want to add these into your system wide profile or .bashrc in order to use TOra. Just to change things up a bit, this time around we’ll add it to the default profile. Oddly this was not working for me directly with sudo, so you will need to get a root shell going to make it happen.


sudo -s
[sudo] password for $you:
echo export ORACLE_HOME="/usr/lib/oracle/11.2/client" >> /etc/profile
echo export LD_LIBRARY_PATH="${ORACLE_HOME}/lib" >> /etc/profile
echo export TNS_ADMIN="${ORACLE_HOME}" >> /etc/profile
exit

And now we have a new player. The last time around I had you create a symlink to the includes for oracle, this time It’s much easier to just use the CMAKE environment variables to point to the include files we need.


export CMAKE_INCLUDE_PATH=/usr/include/oracle/11.2/client

Now on to the main event.

Building and installing TOra

Go to your build directory and you’ll see there is a tora-2.1.1 directory. Change to this directory.


cd /path/to/tora/tora-2.1.1/

Run the script to build the package.


fakeroot debian/rules binary

Depending on your system speed, take a break while the compile runs. Once done, proceed to install it like so.


dpkg -i ../tora_2.1.1-1_i386.deb

The Update Issue

This time around I am going to break out the method of stopping updates to a few methods.

  • Method 1: Using dpkg

    Supports: apt-get, Synaptic

    This is the way I have been doing it through all the blogs in this series. The problem I found with this method is that some GUI package managers do not seem to respect the hold the way I think they should. So I can hold it all I want, but the second I let KPackageKit do an upgrade I am sunk. It also will not survive a dist-upgrade, not even using apt.

    Luckily for me I almost always do it on the command line using apt, so for those inclined as I am you simply need to run this command.


    echo "tora hold" | sudo dpkg --set-selections

    To ensure the change took, look at the package status like so. The response from dpkg is bolded.


    $ dpkg-query --status tora|grep Status
    Status: hold ok installed

    When you are done you should see this if you try to run an upgrade via apt.


    $ sudo apt-get upgrade
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    The following packages have been kept back:
    tora

    If it does not hold the package back, then check your status as above.

  • Method 2: Using aptitude

    Supports: aptitude, KPackageKit

    This method is similar to the above, but has the annoying habit of removing packages when you do it. Sure it’s only removing packages that you no longer need (considered unused by aptitude like old kernels). I personally like to control when packages are removed and adding a hold to a package is not the right time to uninstall things.

    If, after all that, you still want to try it then here is the command you need.


    sudo aptitude hold tora

    I did some searching and I see no method to display this hold status using aptitude. If someone can add a method for this in comments it would be helpful.

  • Method 3: Using $GUI front end

    I know there are quite a number of different package managers out there and most probably support methods 1 and/or 2. If not then you’ll need to figure that one our on your own. Feel free to add the package manager and method in comments.

  • Method 4: Super Guerilla Tactics(tm)

    Supports: Everything

    This method is easy but is not really for the faint of heart. It has the advantage of never having to worry about upgrades again, at least until a much newer version comes out. This method involves changing the package version number before compiling to create a package with a version number that should be higher than anything available in the repository. This needs to be done before you compile, or you can go back and compile it again.

    First, add an entry to the debian changelog file.


    cd /path/to/tora/tora-2.1.1
    vi debian/changelog

    You can see that this file has a series of change log entries with dates and version numbers. Add a new entry to the top of the file as I did with the below example. Be cautious of the spacing and blank lines between entries as the compiler will barf if they are even one space off. Pay particular attention to the 2 spaces between the email address and the date which cannot be replicated on a web page correctly due to html parsing (multiple spaces are not allowed, not even after proper punctuation :O)


    tora (2.1.1-10) unstable; urgency=low

    * Version incremented to avoid upgrades.

    -- Brad Hudson <none@none.net> Thu, 15 Apr 2010 14:00:00 +0500

    tora (2.1.1-1) unstable; urgency=low

    * New upstream version.

    -- Michael Meskes <meskes@debian.org> Thu, 19 Nov 2009 15:18:19 +0100

    Save and exit the file. As you can see, all I did was change the packaged version to -10, which is higher than -1 through -9, meaning there would have to be 9 more official releases before it’ll overwrite your custom package. I did not update the actual code version (everything before the -) so if a version 2.1.2-1 comes out you’ll need to watch for it. These number can be changed to anything you want however (as long as it’s higher), so if you wanted to make sure it was never upgraded even for major version changes, you could set the version to this.


    tora (5.1.1-1) unstable; urgency=low

    The program code will not change through any of this, just the package name.

    Now that you’ve modified the changelog, go back to the build step and recompile everything. When you are done the build can install the shiny new version like so.


    sudo dpkg -i ../tora_2.1.1-10_i386.deb

End Game Re-Redux

Don’t forget your tnsnames.ora. We set up the environment to use TNS_ADMIN=/usr/lib/oracle/11.2/client which means that tora will look for tnsnames.ora there. The easiest way I found was to get the production tnsnames.ora file from the Oracle server itself, and place it in the $TNS_ADMIN directory. Once you have done so, start TOra and enjoy. Remember to start it from the xterm session that has the environment variables set if you have not yet logged out/in.

Once again the build was pretty smooth. I have replicated these instructions 3 times over the course of writing this so there should be very few problems for you if you follow step by step.

As I stated before I could write these up for other distros if anyone is interested. Leave comments if you are.

References

The TOra homepage
Installing TOra with Oracle support on Ubuntu 8.04LTS (Hardy Heron)
Installing TOra with Oracle support on Ubuntu 9.04 (Jaunty Jackalope)
Installing TOra with Oracle Support on Ubuntu 9.10 (Karmic Koala)
Kubuntu linux