On Wed, Nov 08, 2023 at 04:59:46PM +0900, Junio C Hamano wrote: > Patrick Steinhardt <ps@xxxxxx> writes: > > > In order to set up the Apache httpd server, we need to locate both the > > httpd binary and its default module path. This is done with a hardcoded > > list of locations that we scan. While this works okayish with distros > > that more-or-less follow the Filesystem Hierarchy Standard, it falls > > apart on others like NixOS that don't. > > > > While it is possible to specify these paths via `LIB_HTTPD_PATH` and > > `LIB_HTTPD_MODULE_PATH`, it is not a nice experience for the developer > > to figure out how to set those up. And in fact we can do better by > > dynamically detecting both httpd and its module path at runtime: > > > > - The httpd binary can be located via PATH. > > > > - The module directory can (in many cases) be derived via the > > `HTTPD_ROOT` compile-time variable. > > > > Refactor the code to do so. If runtime detection of the paths fails we > > continue to fall back to the hardcoded list of paths. > > Hmph. > > I do not think we would want to punish the distros that follow the > FHS that was created explicitly to help developers by standardizing > locations of various things, with an approach this patch takes that > throws everthing with bathwater and rely on $PATH first. > > Would it be sufficient to please NixOS if we simply append $(command > -v apache) or whatever after the well known candidate locations? I was a bit torn myself when writing this. I can also see a potential future where we would drop the hardcoded list of locations altogether in favor of always using PATH. After all we already rely on PATH to resolve other tools as well, so why should httpd be special there? But in the end I opted to use the more conservative approach of using both PATH and the static list as I didn't want to break other distros. I don't mind to make this even more conservative and resolve via PATH as a last resort, only. Patrick > I know "command -v" is in POSIX, and on both bash and dash (the two > shells most distros use), it works as this patch expects, but its > portability is also a bit worrysome, especially because the whole > point of this patch is to support a platform that is, eh, on the > fringe. > > So, I dunno.
Attachment:
signature.asc
Description: PGP signature
