Items for thoughts:
1. build system using comps.xml for chroot install definitions (base,
build, minimal) - it would make sense and we could leverage the
groupinstall/update/remove mechanism in yum.
2. I talked to Jeremy some about this and I think if we do all rpmdb
transactions from OUTSIDE of the rpmdb and only build in the chroot then
we should be able to safely juggle multiple rpmdb versions from host to
3. there's no reason to not develop a specialized script that uses the
yum modules that can be run by something like mach-helper for making
chroots reasonably correctly.
4. we're going to run into problems with contention for the rpm
transaction lock on the host system b/c rpm likes to lock the rpmdb on
the host system even when operating on the chroot system. A queuing
mechanism for access to the that lock so we know what else is left in
the process is not a bad idea.
From what I can think breaking up the build system into:
something that watches cvs for things to be built
- something that makes/handles/cleans up the chroots
- something that spawns the builds
- something that deals with the results
Is it reasonable to focus on these as modules to be developed?