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

[Peter Maydell]

On 16 July 2014 17:28, Stefan Weil <address@hidden> 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 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