[fedora-virt] qemu/kvm status

[Eduardo Habkost]

On Fri, Feb 13, 2009 at 01:09:53PM +0000, Daniel P. Berrange wrote:
> On Fri, Feb 13, 2009 at 10:59:04AM -0200, Glauber Costa wrote:
> > > We have a problem with any of the above approaches: we don't want to make
> > > the first build a scratch build (we want to keep the build information
> > > stored somewhere on Koji), but we don't want this build to be available
> > > for the users, as the result is an incomplete package. I am thinking
> > > about asking a Koji tag to be created just to store those "intermediate
> > > build step" RPMs. What do you think?
> > > 
> > > 
> > > > 
> > > >   2) We add a "make update-binaries" the makefile - it would do:
> > > > 
> > > >         $> koji download-build $(make verrel)
> > > >         $> rpm2cpio ... | cpio
> > > >         $> tar -cvjf ...
> > > >         $> grep -v etherboot-binaries sources > sources.tmp
> > > >         $> mv sources.tmp sources
> > > >         $> sed -i -e ... etherboot.spec
> > > >         $> make upload FILES=...
> > > 
> > > +1. This should be automated as much as possible.
> > I've talked to some people in #fedora-devel yesterday, for _hours_.
> > 
> > It turns out that they're planning on deploying some features in koji
> > by Feb 28th, that _might_ help us a lot. Really, a lot.
> > 
> > The idea is that you can have your package built on an architecture
> > exclusively with BuildArch directive. But your package can then have
> > a subpackage with BuildArch: noarch. That way, your package will span
> > all repositories. This seems like the perfect solution to us. I've
> > helped them to proceed with some tests, and it seem to work. So what
> > I'm plannin on doing, is post the rpms for review today, since it is
> > unlikely that they will receive more updates in this mean time.
> 
> The main limitation with that approach is the architecture coverage,
> and the way it relates to secondary architectures. This will only
> let us easily do x86 & ppc. If we want sparc, arm or ia64 BIOS, the
> builds would happen in the 2nd arch build ssytem, and the result
> would not be available in our main Fedora YUM repos for primary 
> archs. If we go with your current approach, we can do the build in
> the 2nd-ary arch, and then pull the result back into the packages
> on the primary arches

I don't know if I understood correctly. This means that the new feature
could solve our problems, but it won't solve all of them because some
arches where we need some binaries to be built are second-class citzens
on the build system?

-- 
Eduardo