[Pkg-openldap-devel] Bug#621403: Bug#621403: Bug#621403: Automatic upgrades for Berkeley DB version

[Ondřej Surý]

On Fri, May 13, 2011 at 18:25, Russ Allbery <rra at debian.org> wrote:
> Ondřej Surý <ondrej at debian.org> writes:
>
>> I share your concern and I am not saying you should build-depend
>> openldap on libdb-dev, but that:
>
>> a) you could store the compiled-in version and compare it to used
>> version (and do the upgrade if they differ)
>
>> b) do the upgrade without dump&load, by running dbNEW_upgrade on them
>
>> That would solve the 'dpkg --compare-version "$2"
>> "version-in-unstable"' vs backported versions issue, which was brought
>> up on the debian-backports lists (aka if we backport openldap then the
>> upgrade from backports to next-stable will fail because the package
>> won't know it wants an upgrade).
>
> My recollection is that OpenLDAP upstream doesn't recommend using the
> BerkeleyDB tools to do a direct upgrade and instead recommends using the
> OpenLDAP tools to dump and reload the LDAP database at a higher level.
>
> OpenLDAP uses every nook and cranny of BerkeleyDB in ways that tend to
> stress every weak point of the software, so if my recollection is right,
> straying away from any recommendation about the database handling is
> likely to lead to trouble.

That might be true for database format upgrades, but from my POV I
don't see any risk using Berkeley DB upgrade tools to upgrade only
when the logformat has changed, which is the case for past releases
since 4.3.x. (4.2.x has changed Queue access method). That said I
don't have enough experiences neither with Berkeley DB nor OpenLDAP to
be 100% sure that it's safe to just run dbX.Y_upgrade.

But unless there are actually cases of recent failures in the upgrade
procedure (say from 4.6 up), then I would say that this is just legacy
from ancient times which everybody follows "just to be sure"...

> That said, storing (somewhere) the expected BerkeleyDB version and
> triggering a dump and reload if it changes does seem like a good idea.  I
> would just recommend using the existing dump and reload code that uses the
> OpenLDAP tools.

What about doing:

1. DBOLD_dump > BACKUP
2. try_upgrade (DBOLD_recover && DBNEW_upgrade && DBNEW_checkpoint -1
&& DBNEW_archive -d)
3. if it fails, purge the result and do DBNEW_load < BACKUP

But even Russ's suggestion to store version and do dump&load would
help and I am fine with it...

O.
-- 
Ondřej Surý <ondrej at sury.org>
http://blog.rfc1925.org/