Bug#1119179: reprepro: Depends on db5.3
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.
Bug#1119179: reprepro: Depends on db5.3
On Wed, 2025-12-03 at 00:13 +0100, Guillem Jover wrote:
> Hi!
>
> On Mon, 2025-10-27 at 22:36:08 +0100, Chris Hofstädtler wrote:
> > Source: reprepro
> > Version: 5.4.6+really5.3.2-1
> > Severity: important
> > Control: block 1117120 by -1
>
> > 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.
>
> 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).
I bolted multiple versions support on reprepro (can be found on
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.
--
Benjamin Drung
Debian & Ubuntu Developer
Bug#1119179: reprepro: Depends on db5.3
Hi!
On Mon, 2025-10-27 at 22:36:08 +0100, Chris Hofstädtler wrote:
> Source: reprepro
> Version: 5.4.6+really5.3.2-1
> Severity: important
> Control: block 1117120 by -1
> 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.
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
Bug#1119179: reprepro: Depends on db5.3
Source: reprepro
Version: 5.4.6+really5.3.2-1
Severity: important
Control: block 1117120 by -1
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
