Created attachment 354140 [details] emerge --info File collision between app-emulation/xen-tools-4.3.0 and app-emulation/qemu-1.4.2 ... * * Detected file collision(s): * * /usr/libexec/qemu-bridge-helper * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * app-emulation/qemu-1.4.2:0::gentoo * /usr/libexec/qemu-bridge-helper * * Package 'app-emulation/xen-tools-4.3.0' NOT merged due to file * collisions. If necessary, refer to your elog messages for the whole * content of the above message.
Well I think I can confidently say that qemu won't rename its file from qemu-bridge-helper, so something needs to be updated in Xen.
(In reply to Doug Goldstein from comment #1) > Well I think I can confidently say that qemu won't rename its file from > qemu-bridge-helper, so something needs to be updated in Xen. Yes quite. This appears to force my hand to list app-emulation/qemu as an antogonist package behind use qemu. While seemingly heavy handed, xensource has qemu fully bundled and patched. The problem this creates is by xen maintainer's own design and declaration, they allow for the upstream qemu code and constructs. This blows gentoo out of the water by file collision which is handled by some alternate means in other distros. Let's settle for test request and see what results return. 25 Jul 2013; Ian Delaney <idella4@gentoo.org> files/xenstored.initd, xen-tools-4.3.0.ebuild: Correction to xenstored.initd fix, set app-emulation/qemu as an antagonist dep to IUSE qemu wrt Bug #478064 by uen
The file collision is fixed, but now I can not have qemu and Xen on one system. Because the xen-tools hvm USE flag requires the qemu USE flag. Till now I had one system to test qemu or Xen guests, now I need two systems for this task.
That's why it's heavy handed. I'll see if i can find another solution.
Just to throw in an idea: now that qemu has a xen flag, has anyone tested if normal upstream qemu (with xen support enabled) might just work with xen? I heard that was the grand plan, but I have no idea if we've gotten to the promised land yet...
(In reply to Al Mighty from comment #5) > Just to throw in an idea: now that qemu has a xen flag, has anyone > tested if normal upstream qemu (with xen support enabled) might just > work with xen? I heard that was the grand plan, but I have no idea > if we've gotten to the promised land yet... well big Al, sounds like it beckons a try. The release notes speak of working with upstream qemu so I'd suggest the grand plan might well have arrived. Note the source has qemu and qemu traditional. I'm not in a xen capable system though I do have one, but uen here clearly is trying for both. I'm about to attempt an alternate solution that will turn qemu from antoagonist to a depend.
Right this renames qemu-bridge-helper to xen-bridge-helper in a qemu capable build, evading the file collision and allowing app-emulation/qemu being neither a dependency nor antagonist. 26 Jul 2013; Ian Delaney <idella4@gentoo.org> +files/qemu-bridge.patch, xen-tools-4.3.0.ebuild: Alternate fix of file collision with qemu-bridge-helper with corresponding patch wrt Bug #478064
This works for me, thanks. Now I can have qemu and Xen on one system again.
