[Pkg-gridengine-devel] Bug#621419: gridengine: Uses Berkeley DB transactional environment

[Ondřej Surý]

Package: gridengine-master
Severity: normal

tags 621419 +patch
thank you

Hi,

when checking db4.x->db5.1 transition, I have found that mailavenger
code uses Berkeley DB transactions.  There was a logformat change
between 4.7 -> 4.8 -> 5.0 versions, so you should provide an upgrade
path for your users using Berkeley DB databases.

Upstream documentation can be found at:

http://download.oracle.com/docs/cd/E17076_02/html/upgrading/upgrade_process.html

Please not that there was no change in database format, so the correct procedure is:

If the application has a Berkeley DB transactional environment, and
the log files need upgrading but the databases do not, the application
may be installed in the field using the following steps:


  1. Shut down the old version of the application.

  2. Still using the old version of Berkeley DB, run recovery on the
     database environment using the DB_ENV->open() method, or the
     db_recover utility.

  3. If you used the DB_ENV->open() method to run recovery, make
     sure that the Berkeley DB environment is removed using the
     DB_ENV->remove() method or an appropriate system utility.

  4. Archive the database environment for catastrophic recovery. See
     Database and log file archival for more information.

  5. Recompile and install the new version of the application.

  6. Force a checkpoint using the DB_ENV->txn_checkpoint() method or
     the db_checkpoint utility. If you use the db_checkpoint
     utility, make sure to use the new version of the utility; that
     is, the version that came with the release of Berkeley DB to
     which you are upgrading.

  7. Remove unnecessary log files from the environment using the -d
     option on the db_archive utility, or from an application which
     calls the DB_ENV->log_archive() method with the DB_ARCH_REMOVE
     flag.

     Note that if you are upgrading a replicated application, then
     you should not perform this step until all of the replication
     sites have been upgraded to the current release level. If you
     run this site before all your sites are upgraded, then errors
     can occur in your replication activities because important
     version information might be lost.

  8. Restart the application.


All those steps could also be performed by command line utilities (you
need to depend on db4.8-util and db5.1-util).  (Or you can just use
db4.8_dump and db5.1_load like openldap does.)

Example upgrade script from cyrus-imapd can be found at:

http://git.debian.org/?p=pkg-cyrus-imapd/cyrus-imapd-2.4.git;a=blob;f=debian/cyrus-upgrade-db

I am attaching a patch:

1. Update the debian/control file to build-depend on generic libdb-dev
 and generic db-util + db4.8-util package.  These will keep stable
 for each unstable/stable cycle.  If you want to be extra sure, you
 can change that to:

 Build-Depends: [...], libdb-dev (>= 5.1), libdb-dev (<< 5.2)

 and

 Depends: [...], db4.8-util, db-util (>= 5.1), db-util (<< 5.1)


I am unable to test if the packages compiles with db5.1 because of
#622849, but according to some checks I did, it should.

-- System Information:
Debian Release: squeeze/sid
  APT prefers maverick-updates
  APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500, 'maverick-proposed'), (500, 'maverick-backports'), (500, 'maverick')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.35-28-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gridengine-libdb-dev.patch
Type: text/x-diff
Size: 1124 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gridengine-devel/attachments/20110418/c4591be3/attachment.patch>