Your message dated Wed, 12 Feb 2025 11:53:31 +0100
with message-id <z6x9q-afubvur...@thunder.hadrons.org>
and subject line Re: Bug#1067413: RFP: keydb -- persistent key-value database
with network interface
has caused the Debian Bug report #1067413,
regarding RFP: keydb -- persistent key-value database with network interface
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1067413: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067413
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Chris Lamb <la...@debian.org>, Sascha Steinbiss <sa...@debian.org>
* Package name : keydb
Version : 6.3.4
Upstream Contact: https://github.com/Snapchat/KeyDB
* URL : https://keydb.dev/
* License : BSD-3-clause
Programming Lang: C, C++
Description : persistent key-value database with network interface
keydb is a key-value database in a similar vein to memcache but the dataset
is non-volatile. keydb additionally provides native support for atomically
manipulating and querying data structures such as lists and sets.
.
The dataset is stored entirely in memory and periodically flushed to disk.
This project started as a fork from redis, for improved performance and
multi-threading support. We switched at work to it some time ago, and
had pending sending an RFP/ITP, but given the just announced license
change for redis to make it non-free [L], this seems more relevant now.
We've got the packaging bits around, which I'll try to send to this bug
report, but there's still some work that might be needed before an
upload, at least:
- Unvendor more stuff (we have at least unvendored jemalloc and
rocksdb, but most of the rest need to go too).
- Switch to use _keydb:_keydb as user and group (instead of
keydb:keydb).
- Review and improve the maintscripts (as I think we initially based
our packaging on the upstream provided templates).
I'll try to do this during this week or next one, but if someone would
like to package this right ahead, I can speed this up.
I'm CCing Chris, who might perhaps be interested in replacing Redis with
KeyDB as its spiritual successor and taking this on? Or if not, at least
to perhaps potentially coordinate some kind of transition, even though
we've had issues migrating persistent DBs from newer Redis to KeyDB, so
that might be tricky or not feasible at all. I'm also CCing Sascha who
might be interested (given the keydb packaging repo in salsa). (I'm not
sure we are up for sole maintainership if no one takes this on, but
we'd be happy to give a hand in a team maintainership setting and that
might be an option for us if someone else is interested in driving this.)
[L] https://lwn.net/Articles/966133/
Thanks,
Guillem
--- End Message ---
--- Begin Message ---
Hi!
On Wed, 2024-04-03 at 12:44:46 -0400, Antoine Beaupré wrote:
> After reading https://lwn.net/SubscriberLink/966631/4b4104ce85bf92f7/, i
> have the feeling valkey is probably a better bet for a smooth
> transition. I filed a RFP about it in https://bugs.debian.org/1068342
Given that the main (and only visible?) developer left Snapchat [I], that
there's been no commits in the repo for already 11 months now, and there
are way too many crash reports filed as issues [C] with no response, I
think packaging this in Debian would be mistake.
[I] https://github.com/Snapchat/KeyDB/issues/895
[C] https://github.com/Snapchat/KeyDB/issues?q=is%3Aissue%20state%3Aopen%20crash
At work we have started our migration to Valkey, where for new installs
we already default to that, old ones will get migrated, and we are
currently only stuck with KeyDB for installations that depend on the
active-active support, which we need to see how to get out of. I'm thus
going to close this RFP.
Thanks,
Guillem
--- End Message ---
