I am just interested in why there are three packages for this, qemu, qemu-user and qemu-softmmu. Looking at the ebuild I cannot see any reason to why this cannot be regulated by USE-flag. Would an ebuild trying to unify them be rejected by default?
I was thinking about having a use expand for qemu to let users have a finer grained choice but I never completed it. If you want to try to unify the ebuild so that people needing just the softmmu for amd64/x86 will get just it while people wanting just the userspace will get as well I'll accept it for sure =)
(In reply to comment #1) > I was thinking about having a use expand for qemu to let users have a finer > grained choice but I never completed it. So you mean doing something like SOFTMMU_TARGETS and USER_TARGETS and leaving one of them empty resulting in --disable-system/--disable-linux-user? I will look into it.
Created attachment 190291 [details] unified ebuild for qemu{,-user-softmmu} This ebuilds has kvm placed under softmmu becouse earlier versions (at least 0.10.1) did not build kvm unless a softmmu_target was specified. With qemu-0.10.3 KVM needs linux-headers 2.6.29 or else the includes are missing KVM_CAP_DESTROY_MEMORY_REGION_WORKS so I could not test wheter it is possible to build kvm without softmmus now. The ebuild builds all targets specified. If no targets specified it will still try to build, I have had toughts about setting a guard erroring out unless you have at least one target or kvm set. I also have had thought about making targets "softmmu_target_all" and "user_target_all" building all targets for the specified mode. Please review and comment.
USE="kvm" qemu-0.10.3 depends on bug 266837
I'd like to have a default that is what most users expect so at least some softmmu targets should be +use by default, beside that the ebuild looks nice.
That may be better to set in make.defaults, or it will requiring some extra logic (unless we by default sets all targets). But maybe all by default is a good thing?
That's what is expected so it should be fine, a second step after that is getting prefix and bsd people help testing and unlocking darwin and freebsd userspace.
Created attachment 190298 [details] revised, only update is everything-by-default I am not really sure how this will react if this becomes a USE_EXPAND and how it will work with SOFTMMU_TARGETS/USER_TARGETS (what will have priority), but as long as it only is USE-flags it will work.
Should you take up on the list the propose of adding new USE_EXPANDs?
I hope to get the thing done once the pycon is finished (sorry for the delay)
I am not so good at sed'ing, but I would suggest remove filter-flags and add "CFLAGS+=-fPIC -fno-stack-protector" to Makefile.target, as currently only the targets needs filtering and the tools like qemu-nbd does not.
Filtering -fpie and -fstack-protector doesn't sound really good, but using CFLAGS += in Makefile is even worse, since it's unlikely to be what upstream desires... By the way: -fpie should already enable -fPIC... The test on presence of paxctl doesn't look anywhere near good though, what it should be for?
Ebuild in portage, I hope to add further tweaks soon.
