On Mon, Oct 15, 2018 at 05:50:23PM +0000, Dmitry Bogatov wrote: > [2018-10-15 20:18] Niko Tyni <nt...@debian.org> > > > I am sorry to say it, but probably binNMU or sourceful upload would > > > be required for all packages, that bundle gdbm databases, generated > > > by (gdbm << 1.9) > > > > This sounds really sad. So even the gdbm we have in our current stable > > release is too old to be supported anymore! > > > > Any packaged databases are easily rebuilt, but what about local user > > databases? I think breaking compat with those is horrible, and I don't > > even see a way to recover their contents after they've upgraded gdbm. > > Well, you can use gdbm_dump/stable. What else?
I can't see such a thing; the gdbmtool binary package was only introduced after stretch. Somewhat surprisingly, even gdbm_dump + gdbm_load from 1.14 will generate a "broken" database, though combining gdbm_dump from 1.14 with gdbm_load from 1.18 does work. FWIW I see there used to be a standalone utility called 'gdbmexport' for dumping v1.8 databases, which was removed in 1.15. I managed to build it out of the 1.14.1-6 source package, and it does seem to do the job when paired with gdbm_load from 1.18. > * I can write debian/NEWS to warn about incompatibility. > * We can introduce new source package, that provides gdbmtool > out of gdbm-1.8 (I am not fan of this idea) Could you please at least talk to upstream and see if they would reconsider all this and restore (even just read-only) compatibility with v1.8 databases? If that doesn't work out, I think the right thing to do would be to introduce a statically linked gdbmexport binary package for one release cycle, probably built from 1.14.6 sources. That would give users a way out of this. Clearly part of the issue here is that Debian has been lagging behind upstream for quite a few years until now. Thanks for your work in catching up! -- Niko
