On Fri, Oct 06, 2017 at 04:50:44PM +0200, Pino Toscano wrote:
On Friday, 6 October 2017 15:59:42 CEST Richard W.M. Jones wrote:
The main purpose of this change is two-fold:
(1) Ensure that we run the same version of qemu-img that we are built against.
(2) Allow the qemu-img path to be overridden at build time in case it's on a nonstandard path or (like RHV) has a nonstandard name. ---
As I mentioned in other series, I am not a fan of hardcoding at build time paths used at runtime. This patch has different issues: a) the hardcoding itself (which IMHO is a step backward) b) what the patch does just cover a very minimal set of all the qemu-img invocations; all the tools rely on $PATH c) it is not overridable at all: since qemu can be changed in different ways (API entry, envvar), it is not logic that qemu-img (built from the same sources of qemu) cannot be changed at all; this situation e.g. makes it not possible to use a custom qemu build (that says enables some feature) in libguestfs d) the point (2) above implies supporting RHV would mean rebuilding libguestfs just for that, which makes testing harder than needed
qemu is the "special flower" in this situation, since it can be outside of $PATH (hi RHEL), with a custom name, etc. qemu-img does not have any of the qemu peculiarities.
This is all true, but unless we make qemu-img configurable at runtime (which is extra complexity), I'm not sure what to do about it. FWIW in RHEL qemu-img and qemu-img-rhev both ship /usr/bin/qemu-img. (I previously thought that the binaries had different names, did that change recently or was a I just mis-remembering??) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html