Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases

[Michael Tokarev]

16.07.2014 21:11, Stefan Weil wrote:
> Am 16.07.2014 18:49, schrieb Paolo Bonzini:
>> Il 16/07/2014 18:28, Stefan Weil ha scritto:
>>> Debian testing includes a brand new libiscsi, but it
>>> does not include libiscsi.pc, so pkg-config won't know that it is
>>> available and configure will disable libiscsi.
>>
>> That's a packaging bug.
> 
> CC'ing Michael as he is the Debian maintainer of this package and
> Aurélien who maintains QEMU for Debian.

Actually I maintain both for several years.

> Michael, should I send a Debian bug report for libiscsi-dev? Would an
> update of libiscsi for Debian stable be reasonable if versions older
> than 1.9 are too buggy to be used? I must admit that I'm a little bit
> surprised because iSCSI support worked for me quite well the last time I
> used it with Debian wheezy.

The bug is indeed in libiscsi-dev debian package in testing/jessie, I
forgot to include the .pc file.  Since so far, qemu is the only user of
libiscsi in debian, and since current version of qemu in debian testing
builds with thie libiscsi-dev, the bug went unnoticed.  I'll update the
libiscsi package in a moment, to include the .pc file.  I haven't read
whole thread yet, but I assume that new (2.1-tobe) qemu needs a .pc
file for libiscsi.

More recent libiscsi will _not_ be available directly in debian stable
(wheezy), but I'll provide one in a form of a backport shortly too,
because of exactly this issue.  I'm not sure yet if I'll provide a
backport of libiscsi before doing qemu-2.1 backport, however.

Thank you for the heads-up!

And no, there is no need to tweak qemu for this, the new version
requiriment is here for a reason.

/mjt

>>> I have a patch which
>>> fixes this, so QEMU for Debian testing could include libiscsi again.
>>>
>>> Is a feature regression like this one acceptable? Do we need additional
>>> testing (maybe run the build bots with --enable-xxx, so builds fail when
>>> xxx no longer works)?
>>
>> As mentioned in the e49ab19fcaa617ad6cdfe1ac401327326b6a2552 commit
>> message, this was intentional.  I was reluctant to do it, but ultimately
>> Peter Lieven convinced me that it isn't just about using fancy new APIs;
>> libiscsi was too buggy to be useful until release 1.8.0 (even 1.9.0
>> requires a patch to avoid segfaults, and many more if you want to run it
>> on ARM).
>>
>> Paolo
>