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
yet.
> > 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: