28.01.2026 16:55, Sebastian Reitenbach пишет:
> Hi,
> 
> cat pkg/DESCR:
> OpenVoxDB is a fork of Open Source PuppetDB.
> 
> OpenVoxDB is the fast, scalable, and reliable data warehouse for OpenVox.
> It caches data generated by OpenVox, and gives you advanced features at
> awesome speed with a powerful API.
> 
> Similarly to OpenVox server, it will eventually replace PuppetDB. To 
> eventually support multiple major versions, same structure used as 
> databases/puppetdb.

Makes sense.

I don't think '@pkgpath databases/puppetdb/7' is needed.

infrastructure/db/user.list should mention openvoxdb as well.

patches/ harcodes /var while the .rc file uses LOCALSTATEDIR;
both is fine to me really, but it should be consistent.

patches/ has files with 'env bash' shebangs and do-configure
sed-patches other files to use an absoloute path.  Both work,
but I'd prefer we stick to one way of fixing/using bash.

Strictly speaking, I think, MAKE_FLAGS should be FAKE_FLAGS
since only do-install uses them and NO_BUILD=Yes.

Overall, it'd be nice if openvoxdb and openvox-server Makefiles
would match;  they share a lot, but have churn wrt. V/VERSION,
spaces/no spaces before =, etc. which makes reading harder than
it should be.

> 
> Same as with OpenVox server, between 8.11 and 8.12, they dropped the Makefile 
> with the install target. Therefore using same approach here, and added the 
> old Makefile to the files directory.

I lack the details/background here, but the approach seems fine
except for

- 'rubylibdir ?= $(shell ruby ...)':
  - needs USE_GMAKE=Yes (only openvox-server sets it)
  - should probably use MODRUBY_* stuff to get the binary name
  or not use a shell command at all

- you default 'confidir ?= /etc' and others, bu then also pass
  them in the ports Makefile;  we control both, so wouldn' it
  be simpler to use SYSCONFDIR in files/Makefile right away?

- does it really need to have all the targets we don't use?

> 
> Any concerns, test reports or any other feedback welcome.

I don't run an openvox server/db setup (yet).

> 
> Cheers,
> Sebastian

Reply via email to