[libvirt PATCH] rpm: Don't require qemu-img at build time

[Peter Krempa]

On Wed, May 10, 2023 at 05:28:56 -0700, Andrea Bolognani wrote:
> On Wed, May 10, 2023 at 12:01:03PM +0200, Martin Kletzander wrote:
> > On Fri, May 05, 2023 at 08:05:05PM +0200, Andrea Bolognani wrote:
> > > It's not used as part of the build process or even searched for
> > > at build time. The QEMU driver detects its path at runtime.
> >
> > But we do run tests at build time and virstoragetest.c is looking for
> > qemu-img and using it.  Without it the tests would not fail, but would
> > be skipped, which might be ever worse because we would not notice.
> 
> Good catch! You're right, we definitely don't want that.
> 
> I see that we only have 3 calls to 'qemu-img create' in that test,
> with everything else being done via preformatted images that are
> stored in tests/virstoragetestdata/. Several more calls were present
> in the past, but the vast majority were dropped with [1].
> 
> Peter, is there a reason why we're still calling 'qemu-img create'
> for those specific images? Or could we replace those calls with
> preformatted images as well, and no longer use qemu-img from the test
> suite at all?

The idea why I kept using freshly formatted images is to validate our
qcow2 header parser (we have our own, which is intentionally kept very
simple to only parse the format and backing image location) against the
current state of qemu, to catch potential regressions when qemu's format
would change. It's a form of integration testing albeit a bit weird in
how it's executed (notably it depeds on the system version of qemu-img
rather than doing anything specific to test against current upstream).

Arguably that would not be good for qemu as well when they'd change the
format so incompatibly it so I suppose it's already tested in qemu.

I don't think it would be too much of a loss for downstreams if those
tests were skipped. Replacing it by preformatted images makes no sense
as there are already other tests doing the same, thus only reasonable
other course of actions is to drop the tests entirely.

On the other hand, I don't really think that dropping the build
dependency would simplify or optimize anything.