Dear Maintainer,

your package depends or otherwise uses db5.3 ("Berkeley DB"). The
upstream of db5.3 has ceased maintaining it, and it is also orphaned
in Debian. See #987013 for discussion. Please update your package to
remove any uses of db5.3 for forky.
If necessary, provide an upgrade path in forky and remove usage in
duke.

Chris

For the record,

I am a nosy bystander (who uses apt-ftparchive).

AFAICT the only part of apt using bdb is apt-ftparchive/cachedb.{h,cc} (in the apt-utils .deb).
i.e. people just doing apt update/install/full-upgrade are NOT IMPACTED.

apt-ftparchive reads pool/ and generates dists/.
apt-ftparchive can use a bdb cache to avoid re-processing unchanged files in pool/.
apt-ftparchive can run without a cache -- it's just annoyingly slow (3 seconds vs 351 seconds for an 8GB 3Kinode pool/).
In theory we could just comment out the db references in debian/control, CMake*, and apt-ftparchive/cache*, and most users will not even notice.
(I would, but I am weird.)

If apt-ftparchive is patched to use e.g. liblmdb0 instead of libdb5.3,
we don't need to migrate the data in the cache,
we can just say "delete it and let it be re-created".
(This already happens in ftparchive/cachedb.cc for HASH->BTREE transition within bdb.)

I didn't find a general guid "how to port your C app from bdb to lmdb".
All the search results were Fedora 389 DS users migrating their LDAP database from bdb to lmdb.
(lmdb is originally from OpenLDAP.)

I had a quick crack at porting cachedb.cc from bdb to lmdb, despite not knowing any of the components involved.
I think I got the cmake part working OK.
I didn't get much further because file:///usr/share/doc/lmdb-doc/html/starting.html seems to mandate a longer chain than bdb:

  mdb_env_open()     // path (as char*) to environment
  mdb_txn_begin()    // environment to transaction
  mdb_dbi_open()     // transaction to database (just use NULL as database name)

    # no cursor mode, seen in cachedb.h:CacheDB:Put/Get
    mdb_get()          // transaction+database+key to value
    mdb_put()          // transaction+database+key+value to nothing

    # with cursor mode, needed by cachedb.cc:CacheDB::Clean to remove obsolete key/value pairs
    mdb_cursor()       // transaction+database to cursor
    mdb_cursor_get()   // cursor+key to value
    mdb_cursor_put()   // cursor+key+value to nothing
    mdb_cursor_close() // iff a read-only cursor

  mdb_dbi_close()    // not actually needed
  mdb_txn_commit()
  mdb_env_close()

I also noticed that:

 * You need a txn even for MDB_RDONLY.

 * You need a dbi even if your only db name is NULL.

 * MDB_val is a direct equivalent of DBT (for a key or value).
   It's (usually) zero-copy, so you have to make your own copy if you
   want to refer to it after closing lmdb.
   I'm not good enough at C++ to tell at a glance if ftparchive/cachedb.cc is doing so.

 * I don't think apt-ftparchive is doing threading.
   If it is, you have to care about thread-locality for parts of lmdb.

 * There's no in-place Dbp->compact().
   I think you have to mdb_env_copy2() with MDB_COMPACT flag, then
   I guess manually rotate the copies using renameat2() or whatever.

 * There's no stat_print().
   I think you have to mdb_env_stat() then manually printf() the 6 numbers.