[Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases (was: [ANNOUNCE] QEMU 2.1.0-rc2 is now available)

[Stefan Weil <sw@weilnetz.de>]

Am 16.07.2014 02:26, schrieb Michael Roth:
> Hello,
>
> On behalf of the QEMU Team, I'd like to announce the availability of the
> third release candidate for the QEMU 2.1 release.  This release is meant
> for testing purposes and should not be used in a production environment.
>
>   http://wiki.qemu.org/download/qemu-2.1.0-rc2.tar.bz2
>
> You can help improve the quality of the QEMU 2.1 release by testing this
> release and reporting bugs on Launchpad:
>
>   https://bugs.launchpad.net/qemu/

Hi,

a recent commit (e49ab19fcaa617ad6cdfe1ac401327326b6a2552) increased the
requirements for libiscsi from 1.4.0 to 1.9.0. From a user's point of
view, this change results in a regression for Debian and similar Linux
distributions: QEMU no longer includes iscsi features.

In this special case, the current Debian stable includes QEMU packages
with libiscsi 1.4, but new builds won't include it because that version
is now too old. 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. 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)?

Regards
Stefan