[Refdb-devel] DB_VERSION redux

[David N. <dav...@sw...>]

Hi Markus,

The change in database version in svn has exposed some problems.  First, 
use of refdba and refdbc has not caused /var/lib/refdb/db/DB_VERSION to 
increment from 1 to 2.  I've restarted the refdbd daemon and run clients 
as root but it stays at '1'.  I haven't yet investigated log messages.

The second problem is more complex.  It has to do with how the packaging 
system handles an upgrade in database version.  You may recall the 
unitary refdb package handled this by having the pre-install script 
compare database versions of new package and existing package.  If the 
new database version was higher, then the user was urged to abort the 
upgrade and backup all data.  The backup and restore scripts could 
assist.  The upgrade abort was achieved by having the pre-install script 
exit with a non-zero status.  This forced the package manager to abort 
the upgrade.

Now refdb is split into clients and server packages.  Only the server 
package has the version-checking machinery.  If both clients and server 
packages are running on the same machine, the clients package updates 
but the server package update may be aborted.  This may result in the 
application being unable to access *any* reference data.

The most obvious solution is to use the pre-install script to force a 
data backup (by, say, refdb-backup) and use the post-install script to 
restore the data (by, say, refdb-restore).  The problem is the server 
package may be running on a computer without the clients package.  The 
backup and restore scripts require the refdba and refdbc clients 
supplied by the clients package.  In fact, since both clients are used 
in backing up and restoring reference data, neither operation can be 
done on server-managed data in the absence of the clients package.  The 
relevant client executables cannot be packaged into both packages under 
the same names as this is forbidden by all package managers.  Forcing 
the server package to be dependent on the clients package would, 
however, defeat the purpose of splitting refdb into multiple packages in 
the first place.

What this problem cries out for is a data conversion utility that ships 
with the server package and can be called by pre- and/or post-install 
scripts to upgrade all databases in-place and without user involvement.  
A "poor man's" approach would be to move the backup and restore scripts 
from client package to server package.  The server package would also 
need renamed copies of the refdba and refdbc clients (as they are called 
by the backup and restore scripts).

When DB_VERSION was first added to refdb you declared it to be a "slimy 
hack".  Perhaps now is a good time to implement a more robust solution.

Having fixed the documentation problems, I am now reluctant to post a 
new svn debian package until this "migration" issue is resolved.

Regards,
David.