tags 354413 + patch
thanks
I'm attaching a patch that does the following:
* Build against libdb4.4.
* Include scripts that db_update:s /etc/sasldb2 on upgrade of
sasl2-bin.
The scripts take some steps to ensure that the upgrade fails gracefully
if there is something wrong. However, in a normal state, the upgrade
will proceed unattended (assuming the user has a debconf priority of
high).
Note: unless I'm mistaken, and my tests have been wrong, there is no
change in the hash database format between libdb4.2, libdb4.3 and
libdb4.4. All versions of db_dump, db_load and db_upgrade produce
exactly the same file, apart from the rehashing that results from
db_dump/db_load. Thus, the database update may be unnecessary. I was
surprised to find this because of the lengthy discussion we had some
time ago regarding the necessity to upgrade the database format.
However, I already wrote the scripts, so we might as well be on the safe
side and do the update anyway. For all I know, the format could have
changed and I'm not just smart enough to figure out how to verify it.
Also, the choice of libdb4.4 should not be controversial, IMHO. Several
sites use SASL with libdb4.4 without any problems, and some people seem
to even use libdb4.5. Skipping libdb4.3 will buy us some time before we
have to upgrade again.
However, I want someone else to look at this patch before I commit it. I
kindly request that everyone who reads this does some or all of the
following:
* Apply the patch to trunk. Read the changes in context. Read and
understand every line and attempt to convince yourself that it's
going to work.
* Build the package with this patch. Examine the binary packages
and convince yourself that they're going to work in all cases
that you can think of.
* Install the binary packages on a system where you have 1)
no /etc/sasldb2, 2) an /etc/sasldb2 with no users, 3)
an /etc/sasldb2 with some users and 4) any other scenario that
you can think of. Make sure the upgrade works.
* Attempt the upgrade in a "broken" system; fill your disks or
otherwise make file creation impossible, and make sure the
upgrade breaks gracefully (ie. there is no data loss that a
moderately skilled sysadmin cannot recover from).
* Apply any other tests that you can think of.
Please report your findings to this bug. Please ask others to do the
same. I'd like to make an upload before the end of July, if all goes
well.
I wouldn't like to have this package take a trip through experimental,
because previous experience shows that there were no reports on the
experimental versions despite requests for testing. We try to be as
careful as possible, and then upload to unstable. That way, we get
decent exposure.
--
Fabian Fagerholm <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
