[libvirt] [PATCH 2/2] libxl: fallback to lib probe if pkgconfig file not found

[Jim Fehlig]

On 9/20/18 12:30 AM, Michal Privoznik wrote:
> On 09/19/2018 08:59 PM, Jim Fehlig wrote:
>> With the assumption that all Xen >= 4.6 contains a pkgconfig file for
>> libxenlight, commit 5bdcef13 dropped the fallback check to probe
>> libxenlight with LIBVIRT_CHECK_LIB. At the time it was not known that
>> the various Xen pkgconfig files are in the -runtime package in Fedora,
>> instead of the traditional -devel package. This bug [1] was fixed in
>> Fedora > 28, but until Fedora 28 reaches EOL we'll need to re-introduce
>> the fallback check.
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1629643
>>
>> Signed-off-by: Jim Fehlig <jfehlig at suse.com>
>> ---
>>   m4/virt-driver-libxl.m4 | 22 +++++++++++++++++++++-
>>   1 file changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/m4/virt-driver-libxl.m4 b/m4/virt-driver-libxl.m4
>> index 422ff27022..479d9116a4 100644
>> --- a/m4/virt-driver-libxl.m4
>> +++ b/m4/virt-driver-libxl.m4
>> @@ -29,11 +29,31 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_LIBXL], [
>>     LIBXL_API_VERSION="-DLIBXL_API_VERSION=0x040500"
>>   
>>     dnl search for libxl, aka libxenlight
>> -  LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0])
>> +  old_with_libxl="$with_libxl"
>> +  LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0], [true])
>>     if test "x$with_libxl" = "xyes" ; then
>>       LIBXL_FIRMWARE_DIR=$($PKG_CONFIG --variable xenfirmwaredir xenlight)
>>       LIBXL_EXECBIN_DIR=$($PKG_CONFIG --variable libexec_bin xenlight)
>> +  fi
>>   
>> +  dnl In Fedora <= 28, the xenlight pkgconfig file is in the -runtime package
>> +  dnl https://bugzilla.redhat.com/show_bug.cgi?id=1629643
>> +  dnl Until Fedora 28 reaches EOL, fallback to lib probe if xenlight.pc is
>> +  dnl not found
> 
> Le sigh. So we have to have this in for next what 6 months? :-(
> 
> ACK though

Thanks, I've pushed these.

> <rant>
>    Sure, we can try working around broken packaging, or we can be brave
> and just tell users to install yet another package if they want to have
> xl driver enabled simply because they are using broken package. It's not
> our bug, and we already work around plenty of other bugs for other
> apps/libs.
> </rant>

Nod.

Over the years my ranting about such workarounds has ebbed as they have become 
commonplace throughout the stack: kernel works around hardware bugs, runtimes 
work around kernel bugs, apps work around runtime bugs, ... I've also seen 
workarounds for libvirt bugs :-).

Regards,
Jim