Dear maintainer(s), app-emulation/xen-tools is bundling app-emulation/qemu which adds a bunch of load to security because most issues in qemu reported against Xen affect app-emulation/qemu and most reported vulnerabilities in app-emulation/qemu are affecting app-emulation/xen-tools QEMU copy as well. Please evaluate if we can get rid of the internal copy of QEMU in app-emulation/xen-tools and pull in app-emulation/qemu instead.
well, we've already provided the ability to unbundle the qemu, just we haven't make it default. if people like (also willing to take the risk), they can choose to build app-emulation/xen-tools with USE=system-qemu enabled (thus unbundle the internal qemu) but to your question, I'd still give a NO 1) there are two qemu device models in xen, a) qemu-traditional b) qemu-upstream qemu-traditiaonal is the old code base, we intend to kill it once but fail to do it, because some guest OS - windows VM? have problem to switch to new qemu-upstream once they already using the old (qemu-traditional) what you call *qemu unbundle* can only happen to b) .. so it won't benefit or cost us much to do it see [1] for more information 2) qemu and xen upstream has different release cycle.. currently we are only tracking the xen release version the xen-4.8.0 is actually using qemu-2.7.0 (xen-4.7.1 using 2.4.1), and we highly rely on xen upstream for the bug/security fixes, which mean upstream should guarantee xen-4.8.0 works fine with the bunbled qemu-2.7.0, on the other side, we can't guarantee if the app-emulation/xen/-tools-4.8.0 works with app-emulation/qemu (code may diverse, may break things, xen upstream didn't test the combination) [1] https://wiki.xenproject.org/wiki/QEMU_Upstream
