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

[Peter Lieven <pl@kamp.de>]

Am 16.07.2014 18:46, schrieb Peter Maydell:
> On 16 July 2014 17:28, Stefan Weil <sw@weilnetz.de> wrote:
>> 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)?
> In general, we should try to avoid feature regressions, but it's
> going to be a case-by-case thing. In this particular instance,
> upstream libiscsi don't recommend pre-1.9 for production use
> (as the commit message documents), and I don't think we would
> be doing our users any favours by allowing them to build something
> that's likely to be broken. We should of course flag up this sort of
> "minimum version of our dependencies has been bumped" info in
> the release notes.

I will update the Wiki.

Peter

>
> I think that "does QEMU still build with all the features we need on
> our distro?" has to be testing done by the people who package and
> maintain QEMU for each distro -- they're the only people who know
> which configurations options they enable and which baseline versions
> of their distro they still care about packaging mainline QEMU for.
>
> thanks
> -- PMM