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

Hi!

I took a brief look at this after a request from Mika (CCed), and
checked how difficult/long it would be to switch to something like
gdbm. And it seems it will be a bit of work (with some refactoring
or restructuring included I guess), as the code for bdb seems to be
using "methods" in structs, while gdbm uses functions, and I'm not
sure there's a direct mapping of things, also I'm not sure how or
whether any database migration would be required here. But more
importantly would be what is the desired target database (GDBM,
SQLite, something else) to be used and migration plan here, which I
think only the current upstream maintainer (Bastian :) can answer.


To set expectations right, I have minimal to zero experience as a
reprepro user, I've only delved into the code a few times, and have
also no experience with bdb (or gdbm). We are using this at work,
and we might need to decide how to invest our time around this, which
might also imply switching archive generation tool perhaps if this is
too much work. Although if we decide to keep using it, we might have
to implement this ourselves if bdb goes away, and no one else has
done the database switch (which I'd highly prefer! :D).

Thanks,
Guillem

https://github.com/ionos-cloud/reprepro) several years ago, because my
previous company needed that feature.

Giving just my two cents from that experience: reprepro can gain from
using a proper DB and not just a key-value store. So in case you have to
replace db5.3, I would look at SQLite first.

If I am implementing the database change, I am probably going for SQLite
and not implementing a more relational structure but just use it as
key-value store probably in the same db layout that is applied by
https://docs.python.org/3/library/dbm.html#module-dbm.sqlite3

But I need to address #1095493 first so we can have one database
transition in unstable that encompasses both multiple version support
from current experimental version and the database library change.