Hi Stuart, thank you very much for the review and updates.
On Mon, Oct 11, 2021 at 10:25:57PM +0100, Stuart Henderson wrote: [...] > Hi Sergey. Updated version attached, A few notes on my changes, there > are probably some others too but this is what I remember: > > - reduce unnecessary variables, the UNIT_xxx were only used to pass > to configure and create directories in fake-install. The directory > creation is pointless, so I dropped the variables and passed directly > to configure. > > - move libexec to lib. openbsd standard use for libexec is for > executables invoked by some software. other similar ports use lib for > plugin modules. > > - /var/run and tmp are cleared at boot so must be created by the rc > script, I added rc_pre. there is no point including them in the package > because it gives a false sense that things will work after boot. > > - tidy dependencies > > - use a valid uid for @newuser/@newgroup lines > > - enable tests > > A couple of issues remain: > > - ruby linkage looks a bit wrong, but I think that's on the ruby side > not the unit side. the NEEDED ELF header in unit's ruby module is set to > just "libruby30.so" and not "libruby30.so.0.0", I think this is probably > due to the symlink in /usr/local/lib/libruby30.so -> libruby30.so.0.0 > and/or lack of SONAME in libruby30. Maybe another porter has an idea > what to do with this though I think it's probably not a show-stopper.. > > - rc script nearly duplicates the standard rc_stop section but adds > -QUIT instead of using the default (-TERM). currently the two singals > do the same in unit anyway but comments suggest it is intended for a > graceful shutdown (not yet implemented). I don't think that will work > very well with rc.d anyway (rcctl restart will wait for shutdown, > so you either use 'fast shutdown' and kill active connections, or > use 'graceful' and have a gap while you stop accepting new connections > while draining old). So I think it might be better to drop the rc_stop > function. Will take a look on that and let you know, thank you so much. Two more questions from my side: - the first one is related to support of different versions of programming languages: i.e. lang/python supports three versions, 2.7, 3.8, and 3.9. It's a bit unclear how to implement that, so I need your guidance here; - NGINX Unit supports PHP as well, to compile a corresponding NGINX Unit's module a shared library support needs to be enabled. That's the `--enable-embed' configure option for php, and a couple of files will be installed, a header file and a shared library. > Other than those, it builds and starts ok, I have run out of patience > trying to figure out how to configure to test runtime myself though > (I was looking for a simple static-file config but there is nothing > obvious). However the tests that I've enabled look promising (a couple > of F/E in test_perl_application.py and test_respawn.py, and a couple > of TLS-related ones, looks fairly minor). NGINX Unit has an excellent tests suite and that one based on a recent version of pytest. There's no static-file config, but it's possible to talk to NGINX Unit through a control socket in JSON format. -- Sergey Osokin
signature.asc
Description: PGP signature
