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

[Daniel P. Berrange]

On Wed, Sep 03, 2008 at 06:37:16AM -0400, Perry N. Myers wrote:
> 
> 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.

That can be solved by using consistent conventions in the build scripts of 
each module. Have the build include a YUM config pointing to the nightly
build YUM repo on ovirt.org, and have it use a local cache in some
pre-defined (but overridable) location (eg, $HOME/ovirt-build/yum-cache) and
also have it pull in RPMs from a local repo (eg $HOME/ovirt-build/local-repo).

So by default it'll pull from the website, and if someone does do a local
build of a dependant bit it'll get stuffed into the local YUM repo thus
overriding the build on the website. If you ensure that the 'release'
part of the RPM version numbers always contains something based on the
timestamp, then package versioning will 'just work' between the local
build and the website build eg

eg, the nightly builds would be numbered like

   ovirt-node-1.0.0-1.auto1234556

and the local developer builds would be numbered like

   ovirt-node-1.0.0-1.fred123456

where 'fred' is their local username just to distinguish the RPM from
an automated build. Since RPM ignores alpha characters in version
comparisons, the embedded timestamp in the local build will appear
newer than the latest nightly build. When the next nightly build 
occurrs, that will in turn compare newer, as you'd expect. And the
next day the developer will automatically get that newer RPM from
ovirt.org instead of their older local copy - until they do a newer
build locally. And so on.

> 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.

You could have an ovirt-build repo if there are some helper scripts
that could be useful for developers doing builds, but at its most
generic level each module's build process should be self-contained
and just expect its dependancies to be pre-installed, or in an available
YUM repo - so that it easily translates into an RPM %build script. Any
scripts building across modules can just be optional convenience add-ons
for  developers

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|