[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU rel
From: |
Peter Lieven |
Subject: |
Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases |
Date: |
Wed, 16 Jul 2014 19:37:33 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 |
Am 16.07.2014 18:46, schrieb 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 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
- [Qemu-devel] [ANNOUNCE] QEMU 2.1.0-rc2 is now available, Michael Roth, 2014/07/15
- [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases (was: [ANNOUNCE] QEMU 2.1.0-rc2 is now available), Stefan Weil, 2014/07/16
- 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, 2014/07/16
- Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases,
Peter Lieven <=
- Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases, Paolo Bonzini, 2014/07/16
- Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases, Stefan Weil, 2014/07/16
- Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases, ronnie sahlberg, 2014/07/16
- Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases, Michael Tokarev, 2014/07/16
- Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases, ronnie sahlberg, 2014/07/23
- Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases, Michael Tokarev, 2014/07/24
- Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases, Peter Lieven, 2014/07/16
- Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases, Michael Tokarev, 2014/07/16