Package: netatalk
Severity: normal
tag 621413 +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)
Otherwise the package compiles just fine.
O.
diff --git a/debian/control b/debian/control
index 073d2ec..f06c01f 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Build-Depends: cdbs (>= 0.4.70~),
devscripts (>= 2.10.7~),
debhelper (>= 6),
dh-buildinfo,
- libdb4.8-dev,
+ libdb-dev,
libwrap0-dev,
libpam0g-dev,
libcups2-dev,
@@ -27,7 +27,7 @@ Package: netatalk
Section: net
Architecture: any
Depends: ${shlibs:Depends}, ${perl:Depends}, ${misc:Depends}, ${cdbs:Depends}
-Recommends: ${cdbs:Recommends}
+Recommends: ${cdbs:Recommends}, db-util, db4.8-util
Suggests: ${cdbs:Suggests}
Description: AppleTalk user binaries
Netatalk is an implementation of the AppleTalk Protocol Suite for
