[Slackbuilds-users] RFC: qemu and aqemu

[Robby Workman]

Hi Leo and Stu (and SBo-users):

I've recently switched to using qemu-only for my virtual machines,
and I have some observations / suggestions from the transition.

Leo:

I started out using aqemu as a front-end to simplify the initial
setup, and after upgrading to qemu-1.0, I discovered that aqemu
didn't understand the new version number.  Find attached some
a tarball with some patches from aqemu git - the patchset includes
some usual bugfixes but also a commit adding support for qemu-1.0.
If the result looks okay to you, please submit that and I'll get
it approved and into the repo.


Stu:

I have two suggestions for qemu-kvm, but neither of them should be
done without your approval, nor am I certain that one of them should
even *be* done, so I think it's best to run both of them past you...
First, how about a symlink at /usr/bin/qemu-kvm pointing to 
/usr/bin/qemu-system-x86_64, i.e.:
  ( cd $PKG/usr/bin ; ln -s qemu-system-x86_64 qemu-kvm )
This is so that e.g. aqemu can easily find it without the user 
having to manually tell it where the KVM-equivalent binary is 
located.  I don't think there's any downside to this, and in fact,
if it were the only change I had, I'd just make it in our repo and
be done with it.  However... 

The second suggested change is to strip the package down quite a 
bit.  Basically, I'd like to remove everything that's also shipped
with the regular qemu package so that there's no overlap.  This 
would mean that our qemu-kvm would (optionally) depend on our qemu
package.  Any thoughts on this?

Assuming that's acceptable, I then wonder if it wouldn't be a good
idea to just rename /usr/bin/qemu-system-x86_64 to /usr/bin/qemu-kvm;
after all, the former filename is still a conflict with the qemu 
package.  My concern is simply that a reinstall/upgrade of qemu 
without a subsequent reinstall/upgrade of qemu-kvm would result in
a /usr/bin/qemu-kvm symlink pointing to regular qemu's binary.  
I know that regular qemu supports the -enable-kvm switch now, and 
that there was a big merge of much of the qemu-kvm code into vanilla
qemu, but the guys in #qemu say that qemu-kvm is still the optimal
choice to use. 

All that said, I'm more than willing to do the legwork on this, so
if it's okay with you, just say the word :)

-RW
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aqemu.tar.gz
Type: application/x-gzip
Size: 10627 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20120203/97e8aac1/attachment.bin>