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.