regression in meson build, AC_PATH_PROG lost

[Andrea Bolognani]

On Fri, 2020-11-20 at 13:58 +0100, Martin Kletzander wrote:
> On Fri, Nov 20, 2020 at 12:24:38PM +0100, Andrea Bolognani wrote:
> > 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.
> 
> This should be handled by a package maintainer who would put such requirement
> into the package for libvirt-deamon-driver-storage-zfs (or similar).  It would
> just be in Requires instead of BuildRequires.  Or DEPEND instead of RDEPEND.
> And based on what you say that's actaully what debian does, just with a hackish
> workaround.

As I explained earlier, in the case of zfs the workaround is needed
for licensing reasons.

In retrospect, zfs is probably not the best example, so let's use
iscsiadm instead: in this case too, without this command the
corresponding driver can't work properly, but such dependency is not
as obvious as the one between the iscsi-direct driver and libiscsi.

> I understand that if we add new functionality that depends on a new binary and
> it only fails at runtime then it might happen that the maintainer misses it and
> people will run into an issue.  It's most probably not going to be a regression,
> though.  And we need to document it somewhere anyway.  And my understanding is
> that the maintainer should at least roughly look at the changes.  Maybe if we
> had like a purpose built file in the repository that would document the building
> process and requirements so that it was easier to filter the changes between
> releases to figure out if the build needs changing.  Oh, wait, we have
> libvirt.spec.in ;) Honestly, I would not be against having the same file in the
> repo for every distro that ships libvirt, but that's another discussion.  But
> anyway, just checking for changes in the spec file is enough.

The spec file is of course the first thing I look at when I'm wearing
my Debian maintainer hat and I'm in the process of importing a new
version of libvirt :) And I skim through the overall changes too, but
the diff between subsequent libvirt releases is usually so massive
that it's simply not realistic to expect that no detail will ever be
missed in the process.

Anyway, the above seems to assume that the spec file is a perfect
representation of requirements at all times, which is not necessarily
the case; and our CI, of course, only *builds* the RPMs, so if all
the checks happen at runtime it has no chance of catching mistakes...

Moreover, there are people who are building libvirt from source, and
for those getting a build time warning/error is definitely a better
experience than having to sift through the spec file to figure out
for themselves all the runtime dependencies that are not tracked by
the build system.

Lastly, if we stopped looking for commands at build time we would be
enabling features that can, in reality, never work: iscsiadm, for
example, is Linux-only, but if we removed the corresponding build
time check we would start building the iscsi storage driver, which
requires the command to be present, on FreeBSD and macOS too. This
would be incredibly misleading and, well, just plain wrong IMHO.

> > 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.
> 
> I would just like to know if there is anyone who needs them overridable for any
> other reason than to disable the build-time check.  Because if no, then we're
> just talking about adding pointless complexity.

As far as the Debian packaging is concerned, having the ability to
override the command for zfs-related tools would be enough.

-- 
Andrea Bolognani / Red Hat / Virtualization