Ondřej Surý <ond...@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 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. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
