On 2021/10/12 21:58, Sergey A. Osokin wrote: > 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;
We support one primary version at a time for each major python release. So for 2.x it's now 2.7, but previously was 2.6, 2.5, ... And for 3.x it's currently 3.8 and will move to 3.9 sometime when the rest of the ports tree is ready. Apart from the core python packages, we don't do builds for multiple 3.x versions. It is possible in an individual port to use an alternative version but that is really a last resort (the only time I remember this ever happening was holding back to py3.7 for blender and maybe some other port needed by blender, because it was holding us back updating to 3.8.. but this is not at all common). If there's a particularly strong use case for providing a py27 unit module then it would be possible to do that, but it's awkward to do that, and we're trying to avoid adding any new ports using 2.7. (Some people are building from ports with the default version set to 3.9 locally, some things work but others are broken, but this probably gives them a way to run unit with 3.9 if they need - we can't really handle that for packages though). > - 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. Will need to have a think about how to handle that in ports, we already build apache sapi (plus cli/cgi/fpm/phpdbg) and php doesn't support multiple sapi in a single build, so the ports setup will need some bigger changes to do this (and I think will probably mean building php twice for each supported version). > > 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. Oh I meant serving static-files, not file-based config (I understand about the control socket) - the step-by-step examples at the top of the quick start docs are for php which obviously isn't supported yet, and it's not until later in that page that serving static files are mixed in, but at that point it's big config chunks and no longer step-by-step, so I found it hard to learn the basics from that doc. (I looked at unit a couple of years ago too and had the same, it seemed interesting but hard to get started with, besides I _like_ old fashioned config files where I can add comments and don't need to remember special commands to load them :)
