Am 16.07.2014 18:46, schrieb Peter Maydell: > On 16 July 2014 17:28, Stefan Weil <s...@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
