couchdb-pkg
couchdb-pkg copied to clipboard
Create RPMs for Nouveau and extend CouchDB RPM to optionally include Nouveau
The next version of CouchDB (3.4.0) will include a new component for full text search called Nouveau. Nouveau is a Java project that integrates with the rest of CouchDB which is written in Erlang.
We’d like the following scenarios to be handled:
- [ ] A user installs the regular Apache-CouchDB-3.4.0.rpm (the real name might be different) via
yum install couchdb. They are not interested in Nouveau, so nothing changes for them. However, Nouveau binaries are installed on the system (this is partially already handled: https://github.com/apache/couchdb-pkg/blob/main/rpm/SPECS/couchdb.spec.in#L99-L103)- [ ] Same as before, but user IS interested in Nouveau, they can run
yum install couchdb-nouveauon the same server and get Apache-CouchDB-Nouveau-3.4.0.rpm installed on the same system and now the following happens:- [ ] the installation of Nouveau creates a new config file in the CouchDB conf.d dir at
/opt/couchdb/etc/local.d/nouveau.ini - [ ] the installation calls the
/_node/_local/_config/_reloadendpoint to activate the new config file, or prompts to restart CouchDB, or directly restarts CouchDB.
- [ ] the installation of Nouveau creates a new config file in the CouchDB conf.d dir at
- [ ] Same as before, but user IS interested in Nouveau, they can run
- [ ] A user wants to run Nouveau on a separate server, so the Apache-CouchDB-Nouveau-3.4.0.rpm installation should not try to augment the
local.dconfig dir and reload CouchDB config, as it has no access to it.
—
We have this working for the Debian packages, look there for inspiration: https://github.com/apache/couchdb-pkg/tree/main/debian
That's a good ideal solution. Initially I think we were going with an intermediate solution if this one proved too difficult.
All the artifacts in one RPM, with both a couchdb service unit file and nouveau unit service file.
By default couchdb service is enabled and nouveau disabled. Configuration can be altered at install time via a environment variable like we do with a COUCHDB_COOKIE.
- By default, just couchdb and nouveau disabled: no change from current setup:
COUCHDB_COOKIE ... rpm -i ... - Enable couchdb and nouveau:
COUCHDB_NOUVEAU_SERVICE=1 ... rpm -i ...or - Just nouveau as standalone:
COUCHDB_SERVICE=0 COUCHDB_NOUVEAU_SERVICE=1 ... rpm -i ...If nouveau is enabled but a compatible JVM is not installed it will stop with an error message.
At runtime users can then enable either service at will via systemd unit commands systemctl enable ...
I am lacking context but that does feels oddly complicated.
Why isn't it just like this?
couchdb -optional-> couchdb-fts
couchdb-fts:
post-install:
if local couchdb
reload
Each package exposing binaries, configs and services.
@tcurdt we’re looking for someone to help us encode this into the existing package definitions