[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#879203: RFP: redisearch -- search engine on top of Redis

[Chris Lamb, 2017-10-24]
> Am happy to package this, and probably makes sense as the Redis
> maintainer anyway.
> > I chose redis-modulename as binary package name
> So, "redis-redisearch". The only problem is that this *somewhat*
> collides with other packages in this namespace, such as redis-sentinel
> and redis-tools (which are not modules). So, one alternative might be
> "redis-module-redisearch" or "redis-modules-redisearch" but I find
> them to be a little too ugly.

or there can be few exceptions from the rule, just like we have
"python-all" in Python

> > /usr/lib/redis/ but maybe /usr/lib/redis/modules/ is a better idea.
> /usr/lib/redis/modules/ wfm. (We don't need to gnu-triplet-these for
> multiarch do we?)

If upstream supports it (IIRC I saw it somewhere, but it might be
ramp-packer only) that would be great, but I'm afraid it's not the case

> > so support for /etc/redis/conf.d/ or autoloading modules from given dir
> Hm, do we even *want* autoloading modules? I'm not 100% sure we do. I guess
> it does not block the packaging anyway...

as an upstream I'd go even further and make it possible to block loading
modules from client (runtime), but that's probably just me.

Reply to: