From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52374) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X7S4A-0008O2-KI for qemu-devel@nongnu.org; Wed, 16 Jul 2014 12:28:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X7S45-00007V-VY for qemu-devel@nongnu.org; Wed, 16 Jul 2014 12:28:26 -0400 Received: from [2a03:4000:1::4e2f:c7ac:d] (port=37497 helo=v220110690675601.yourvserver.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X7S45-00007C-Ok for qemu-devel@nongnu.org; Wed, 16 Jul 2014 12:28:21 -0400 Message-ID: <53C6A816.9090306@weilnetz.de> Date: Wed, 16 Jul 2014 18:28:06 +0200 From: Stefan Weil MIME-Version: 1.0 References: <20140716002632.23073.40357@loki> In-Reply-To: <20140716002632.23073.40357@loki> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases (was: [ANNOUNCE] QEMU 2.1.0-rc2 is now available) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, Peter Lieven 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