Dear maintainers, The Tokyo Cabinet library has been deprecated upstream for many years, Given its age and lack of upstream maintenance, Tokyo Cabinet is starting to show increasing issues (see e.g. #1114412). Therefore, there is an ongoing effort to remove Tokyo Cabinet from Debian. This effort is tracked with bug #1131879. Upstream explicitly recommends Tkrzw [1] as the successor, and it should be considered the preferred migration target. Note: While Kyoto Cabinet [2] has historically been suggested as a replacement, it is in a similar situation today (limited maintenance and aging code), so migrating to it may not be a long-term solution. Upstream recommends Tkrzw as the successor of Kyoto Cabinet. Alternatively, it may be worth considering other supported backends or making Tokyo Cabinet support optional, if applicable. For duc, it seems upstream supports other database backends,[3] lists: - Tokyo Cabinet: tokyocabinet - LevelDB: leveldb - Sqlite3: sqlite3 - Lightning Memory-Mapped Database: lmdb - Kyoto Cabinet: kyotocabinet - Tkrzw: tkrzw (default as of v1.5.0) with the default of tkrzw [1] https://dbmx.net/tkrzw/ [2] https://dbmx.net/kyotocabinet/ [3] https://github.com/zevv/duc/blob/master/INSTALL#L91
OK, this makes sense. Upstream are moving to default to Tkrzw as you point out so that would be the obvious choice. Switching the build over should be easy, but I ned to think a little bit about whether or how to migrate user's existing databases, if at all.
OK, this makes sense. Upstream are moving to default to Tkrzw as you point out so that would be the obvious choice. Switching the build over should be easy, but I ned to think a little bit about whether or how to migrate user's existing databases, if at all.
Ah, a wrinkle. We package the last release which was 1.4.6 and does not support Tkrzw:
I just reviewed the current situation. duc-in-Debian (1.4.6) uses tokyocabinet as the default DB format and does not have support for Tkrzw. Upstream are adding Tkrzw and moving to using it as the default. So at some point in duc's future we will need to handle a database migration, and minimise inconvenience for existing users. There has been no visible activity upstream on this for about 6 months. Last I looked the 1.5* RC branches required quite a lot more work before they would be suitable for release. It's hard to estimate when, or indeed if, this work will land. I'd estimate that Forky will ship mid-2027, so freezes will start in Q1 or Q2 2027. I'm not confident that we will have a duc with Tkrzw before freezes start. We *could* migrate duc-in-Debian to some other DB in time for Forky, but then we would likely be subjecting duc users to two migrations, once Tkrzw lands (or: significantly deviating from upstream on default DB). I'd like to avoid that. I also don't know how well-tested the other backends are. I'd note that I've not had any reports of problems with tokyocabinet from duc users, nor have I hit any myself. It doesn't look to me that tokyocabinet is going to be dropped from Forky, so I think it's best we leave duc using tokyocabinet for Forky and look to move for Forky+1 (that would be my suggested target for removing tokyocabinet from Debian, too)