regression in meson build, AC_PATH_PROG lost

[Andrea Bolognani]

On Fri, 2020-11-20 at 01:19 +0100, Pavel Hrdina wrote:
> On Thu, Nov 19, 2020 at 11:38:28PM +0100, Martin Kletzander wrote:
> > Right now, IMHO, all meson checks for binaries that are not needed at build time
> > should be removed.  During runtime we can just use the name of the binary.  I
> > don't know whether it used to be the case that it was thought that there might
> > be security issues with supplying different binary in a directory in $PATH, but
> > frankly, if you have (different-)user-writable directory in $PATH or non-root
> > access to modifying system-wide $PATH then you have bigger problems to deal
> > with.  Even though I do not have anything to back this claim I think that
> > might've been the original reason.
> 
> That was my take on the original reasoning as well. I completely agree
> here with Martin and vote for removing these runtime binary checks from
> meson completely. There would be also the benefit for testing purposes
> that you can simply change the path to use your own compiled binary
> without changing anything in libvirt.

While I would love the simplification such an approach would yield,
I have to point out that there is at least one advantage to checking
for the availability of commands at build time, even if those
commands will only ever be invoked at runtime: it makes it obvious
those commands are going to be needed later on.

Take the zfs example again: if there was no build time checking, one
might very reasonably assume that the zfs storage driver is usable on
its own (the same way the iscsi-direct driver, for example, is); the
fact that this is not the case would only become apparent much later,
as you attempt to perform some storage operation and get back a
failure.

So while libvirt obviously needs to be able to cope gracefully with
the commands that were detected at build time not being present at
runtime (which would indicate a packaging bug), I'm not convinced
that dropping the build time checks is the best solution. Making them
overridable, as they were with autotools, sounds like a more solid
approach; and for those commands where we don't already check at
build time, such a check should probably be introduced.

-- 
Andrea Bolognani / Red Hat / Virtualization