[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Ovirt-devel] RFC w/o PATCH: Renaming oVirt RPMs

Daniel P. Berrange wrote:
On Wed, Sep 03, 2008 at 06:19:58AM -0400, Perry N. Myers wrote:
Daniel P. Berrange wrote:
On Wed, Sep 03, 2008 at 06:08:15AM -0400, Perry N. Myers wrote:
I'm not opposed to having separate repos for:


Though it does change our build environment drastically since the notion of 'build-all' completely breaks. Any suggestions for how we should incorporate build-all into this new layout?
Don't have a build all. A developer working on the WUI has no need to build
the managed node, and vica-verca. They can use pre-built RPMs of the bits
they are not working on. Autobuild is specifically designed to be able to
do end-to-end builds of a set of dependant packages, and report on them
Ok, right now everyone that works on oVirt uses build-all extensively... and most of those folks don't have access to an autobuild server to automate the process for them. So we need some replacement for build-all for people in the community who want to build from scratch instead of using prebuilt appliance.

So just saying 'don't have build-all, use autobuild instead' is not really a valid option unless we replace it with something equally easy to use...

Well the whole idea is to have stable, reliable interfaces between the
modules. So if you want to work on / build the latest WUI code you can
download the latest pre-built managed node binary from the ovirt.org website, and not have to worry about building something you're not interested in changing. In the scenario where you really do want to build
all 4 pieces from scratch, its really not that hard to type 'build' in
each of the 4 directories. If it was too troublesome, you could even create a shell script 'build-all' to run

 for i in node server appliance ; do (cd $i && build ) ; done

It would be trivial to make the auto-build output available too - we could
simply add a post-build stage to it which publishes nightly RPMs onto the
public oVirt website FTP area, so latest binaries are always available
for working against,
As a comparison - consider someone working on Fedora - they don't want
a build-all script for everything in Fedora - they only care about building
the package they're playing with. Or someone working on virt-manager - they
don't neeed a 'build-all' script which builds Xen, libvirt, and virt-amanger
all in one go - they simply use a pre-built Xen & libvirt binary, and only
focus on the bits they care about.

That model works fine for:
1. Someone only working on the Server and can just use last available version of Node 2. Someone only working on the Node and can just use last available version of Server

What about:
Someone working on integration between Server and Node and needs to build both?

build-all cannot be trivialized into a for loop that does build on all for separate git checkouts. It's more involved than that. We use a common tmp directory for yum cache to build the node and appliance. And RPMs generated from ovirt-node and ovirt-server would need to get placed into that cache for build of ovirt-node-image and ovirt-appliance.

build-all.sh could be used as we use it now even with 4 separate repos underneath it, but the question becomes 'what repo does build-all.sh live in?' given that it is fairly complex. Hmm. Perhaps we need an 'ovirt' repo that contains build-all.sh and things like ovirt-release RPM build.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]