-------- Original Message --------
Subject: Re: [Refdb-users] Debianising RefDB
Date: Sun, 03 Apr 2005 13:38:02 +0930
From: David Nebauer <davidnebauer@xxxxxxxxxxxx>
To: David Nebauer <davidnebauer@xxxxxxxxxxxx>
References: <424D534B.2030002@xxxxxxxxxxxx>
<424EC8BB.1000505@xxxxxxxxxxxx>
David Nebauer wrote:
6. The /usr/share/refdb/db/refdb database
Currently the post-install script looks for the default refdb
database. If not found, it is created from the sqlite dump file.
I think it would be good to include a post-install check of any
existing refdb database. This check would ensure the database is
compatible with the new version of refdb (during an upgrade, for
example). If not compatible, the user is warned.
I have found one solution, but I don't think it is ideal. I use the
the preinst script to test the db version (using the db version file
Markus is currently adding support for). If there is a version
mismatch the user is given the option of aborting the upgrade in order
to follow instructions I will place in an UPGRADE.Debian file. If the
user chooses to abort, the preinst script exits with a non-zero
status. This causes dpkg to abort the upgrade. I'll probably burn in
debian maintainer hell for abusing the preinst script this way but
it's the only practicable solution I could think of.
I'm submitting the preinst script for scrutiny. This is for two reasons:
1. The script must not fail (non-zero exit status) unintentionally since
this will abort the installation. Note the 'set -e' which will cause
the script to do just that if any command (outside of while loops, test
statements and && or || constructs) should fail.
2. The script must be portable between OSes. I've tried to avoid any
esoteric commands. Would those of you who script for non-Linux OSes
please check this script.
You will see the script assumes the existence of a file 'DB_VERSION' in
the database directory which contains no content except the database
version of the installed refdb.
You will also see that variable 'dpkg_db_version' is set to
'<dbversion>'. During the build process this value is changed to the
database version of the new refdb build.
..................................................................................................................
#! /bin/sh
# preinst script for refdb
#
# see: dh_installdeb(1)
set -e
# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.
#DEBHELPER#
# add custom stuff here so comes after auto-generated stuff
# VARIABLES
refdbdrc="/etc/refdb/refdbdrc"
default_dbpath="/var/lib/refdb/db"
dpkg_db_version="<dbversion>"
update="/usr/share/doc/refdb/UPDATE.Debian"
dbdir="" # will define later
version_file="" # will define later
db="" # will define later
# PROCEDURES
# Discover refdb database directory
# params: nil
# return: dbpath
# Note:
# There is a bootstrapping problem here -- we'll check the
# init file for a dbpath, but refdbd can be started with the
# '-y' option to specify another init file or with '-q' to
# the init file.
# If it is a user's practice to do either of these, then this
# procedure may return an inaccurate path.
# I can't as yet see a way to accommodate these 'edge' cases.
get_dbdir () {
retval=""
# first check refdbdrc
if test -r ${refdbdrc} ; then
while read refdbvar refdbval; do
if [ -n "${refdbvar}" ]; then
if [ "${refdbvar}" = "dbpath" ]; then
retval="${refdbval}"
fi
fi
done < ${refdbdrc}
test -d ${retval} || retval="" # check for sane value
fi
# if no dbpath found, use default
test -z "${retval}" && retval="${default_dbpath}"
# return empty string if dir non-existent
test -z "${retval}" && retval=""
# return db dir
echo ${retval}
}
# Get user response (yes|no)
# params: 1 - title
# 2 - message
# return: nil
# errval: 0 (Yes) | 1 (No) | 255 (ESC)
displayYesNo () {
dialog --title "${1}" \
--defaultno \
--yesno "${2}" 0 0
return ${?}
}
# can set more variables now
dbdir="$(get_dbdir)"
version_file="${dbdir}/DB_VERSION"
db="${dbdir}/refdb"
msg_inst_older="WARNING: This new version of RefDB has a modified system
database (${db}) -- its format has changed.\n\nWhen this happens it is
possible RefDB tools will no longer be able to access your data
correctly.\n\nIf you have not done so already, you are *strongly* urged
to abort this upgrade and follow the instructions in <${upgrade}> for
backing up your data and preparing to rebuild the system
database.\n\nWARNING: You should *not* proceed until you have backed up
your data and prepared to rebuild the system database.\n\nDo you wish to
proceed with this upgrade?"
msg_inst_newer="WARNING: This new version of RefDB has a modified system
database (${db}) -- its format has changed. The RefDB tools are
configured for a database version *lower* than that of the currently
existing system database. This can occur when changing from a CVS
version of RefDB to a pre-release or stable release version.\n\nIt is
possible, though not certain, that RefDB tools will no longer be able to
access your data correctly after the upgrade.\n\nIf you have not done so
already, you are *strongly* urged to abort this upgrade and follow the
instructions in <${upgrade}> for backing up your data and preparing to
rebuild the system database.\n\nWARNING: You should *not* proceed until
you have backed up your data and prepared to rebuild the system
database.\n\nDo you wish to proceed with this upgrade?"
msg_inst_unknown="WARNING: Unable to detect a version file
(<${version_file}>) on your system. This is highly unusual since
'refdbd' creates/overwrites this file every time it is run. Without
access to this file it is not possible to determine whether the RefDB
system database has changed version in this upgrade. If the database
version *has* changed it can mean RefDB may no longer be able to access
your data correctly.\n\nWhat does all this mean? You should abort this
upgrade and run 'refdbd' to re-generate the database version file before
trying to upgrade again.\n\nWARNING: You should *not* proceed until you
have corrected this problem.\n\nDo you wish to proceed with this upgrade?"
# MAIN
# summary of how this script can be called:
# * <new-preinst> `install'
# * <new-preinst> `install' <old-version>
# * <new-preinst> `upgrade' <old-version>
# * <old-preinst> `abort-upgrade' <new-version>
#
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package
case "$1" in
install)
;;
upgrade)
if test -r "${version_file}" ; then
# get installed db version
inst_db_version="$(cat ${version_file})"
# installed (old) and dpkg (new) versions have three
# possible relative states:
# 1. dpkg > installed
if test ${dpkg_db_version} -gt ${inst_db_version} ; then
displayYesNo "RefDB upgrade" "${msg_inst_older}"
test ${?} -ne 0 && exit 1
elif test ${dpkg_db_version} -lt ${inst_db_version} ; then
# 2. installed > dpkg
displayYesNo "RefDB upgrade" "${msg_inst_newer}"
test ${?} -ne 0 && exit 1
#else
# 3. dpkg = installed
# nothing to do
fi
else # error! no version file detected
displayYesNo "RefDB upgrade" "${msg_inst_unknown}"
test ${?} -ne 0 && exit 1
fi
;;
abort-upgrade)
;;
*)
if test -z "${1}" ; then
echo "preinst called with no argument" >&2
else
echo "preinst called with unknown argument '${1}'" >&2
fi
exit 1
;;
esac
exit 0
..................................................................................................................
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
|
