On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote: > hi, > yesterday i try to rebuild fedora packages for rhel/centos/epel-5 and > i've got a few comments. i try to build these packages: Are you actually going to import them into EL-5? I discussed with lkundrak already doing that for just qemu.

[...] > - in more package the in the subpackage "Group field must be present in > package", so group name missing:-( and bacuse of this none of openbios, > bochs-bios and etherboot can be build on epel:-( Has RPM changed so it no longer requires the Group field? It was a pretty useless field anyway.

On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote: > - libvirt BR qemu. why? which require all qemu package which require > openbios-ppc, vgabios, bochs-bios-data, etherboot-*. so this is a > dependency hell. imho it'd be useful to clean up! The build process wants QEMU so its a BR. There is no dependancy hell here unless you're using the wrong tools. mock trivially pull in the chain of deps as needed during build, so there's nothing to 'clean up'.

> - this /etc/libvirt/qemu/networks/default.xml makes me crazy. since blow > up my current guest's configs:-((( That will only be created if it doesn't exist, so it will not impact things unless you have created another network with a clashing IP address range, which is trivially avoidable.

On Fri, May 22, 2009 at 01:23:06PM +0200, Farkas Levente wrote: > Daniel P. Berrange wrote: >> On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote: >>> - libvirt BR qemu. why? which require all qemu package which require >>> openbios-ppc, vgabios, bochs-bios-data, etherboot-*. so this is a >>> dependency hell. imho it'd be useful to clean up! >> The build process wants QEMU so its a BR. There is no dependancy hell >> here unless you're using the wrong tools. mock trivially pull in the >> chain of deps as needed during build, so there's nothing to 'clean up'. > i can't build (since i don't have ppc) but i need it for qemu-system-ppc > which is needed by qemu which is needed by libvirt:-( > are you sure all of these req and br are required? You're not making any sense here. You don't need a ppc host, to build qemu-system-ppc. All host architectures can build all QEMU targets, you're not restricted to matching host & qemu target, with the exception of KVM.

>>> - this /etc/libvirt/qemu/networks/default.xml makes me crazy. since blow >>> up my current guest's configs:-((( >> That will only be created if it doesn't exist, so it will not impact >> things unless you have created another network with a clashing IP >> address range, which is trivially avoidable. > but if it's not exist then it's created and all guest will suddenly have > a new interface which may interfere with the existing network which is > very hard to find the reason!:-( This only creates a bridge on the host. No guest is connected to this bridge unless you configure it that way. So merely having the config does not affect existing guests

On Fri, May 22, 2009 at 02:04:28PM +0200, Farkas Levente wrote: > Daniel P. Berrange wrote: >> On Fri, May 22, 2009 at 01:23:06PM +0200, Farkas Levente wrote: >>> Daniel P. Berrange wrote: >>>> On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote: >>>>> - libvirt BR qemu. why? which require all qemu package which require >>>>> openbios-ppc, vgabios, bochs-bios-data, etherboot-*. so this is a >>>>> dependency hell. imho it'd be useful to clean up! >>>> The build process wants QEMU so its a BR. There is no dependancy hell >>>> here unless you're using the wrong tools. mock trivially pull in the >>>> chain of deps as needed during build, so there's nothing to 'clean up'. >>> i can't build (since i don't have ppc) but i need it for qemu-system-ppc >>> which is needed by qemu which is needed by libvirt:-( >>> are you sure all of these req and br are required? >> You're not making any sense here. You don't need a ppc host, to build >> qemu-system-ppc. All host architectures can build all QEMU targets, >> you're not restricted to matching host & qemu target, with the exception >> of KVM. > i wrote above i can't build openbios-ppc which required by qemu etc...so > i can't build libvirt:-( Then just disable the qemu-system-ppc bits in QEMU. It really isn't hard to remove the ppc sub-RPM and change the target-list for the QEMU build to turn off ppc.

On Fri, May 22, 2009 at 09:41:01PM +0200, Farkas Levente wrote: > Daniel P. Berrange wrote: >> On Fri, May 22, 2009 at 02:04:28PM +0200, Farkas Levente wrote: >>> Daniel P. Berrange wrote: >>>> On Fri, May 22, 2009 at 01:23:06PM +0200, Farkas Levente wrote: >>>>> Daniel P. Berrange wrote: >>>>>> On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote: >>>>>>> - libvirt BR qemu. why? which require all qemu package which require >>>>>>> openbios-ppc, vgabios, bochs-bios-data, etherboot-*. so this is a >>>>>>> dependency hell. imho it'd be useful to clean up! >>>>>> The build process wants QEMU so its a BR. There is no dependancy hell >>>>>> here unless you're using the wrong tools. mock trivially pull in the >>>>>> chain of deps as needed during build, so there's nothing to 'clean up'. >>>>> i can't build (since i don't have ppc) but i need it for qemu-system-ppc >>>>> which is needed by qemu which is needed by libvirt:-( >>>>> are you sure all of these req and br are required? >>>> You're not making any sense here. You don't need a ppc host, to build >>>> qemu-system-ppc. All host architectures can build all QEMU targets, >>>> you're not restricted to matching host & qemu target, with the exception >>>> of KVM. >>> i wrote above i can't build openbios-ppc which required by qemu etc...so >>> i can't build libvirt:-( >> Then just disable the qemu-system-ppc bits in QEMU. It really isn't hard >> to remove the ppc sub-RPM and change the target-list for the QEMU build >> to turn off ppc. > this means even on a primary platform ix86 these packages can't be > rebuild without modification. > wouldn't be easier to put back openbios-ppc, vgabios, bochs-bios-data, > etherboot into qemu? These packages were split out from QEMU because, they were duplicating functionality in Bochs & QEMU packages. It was also not clear that they were in compliance with the license, because there was no corresponding source to the pre-built binary being shipped. You fundamentally can't build many of these packages on all archs. This last reason is the real key bit. openbios-ppc can only be built from source on a PPC host, so we need to build on PPC, and then include that built binary on a 2nd build on all other archs. The only practical way todo this is if the BIOS is separate from QEMU, otherwise you end up havig to rebuild far too much stuff each time.