On Wed, 2005-03-02 at 17:38 -0500, seth vidal wrote:
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.
Frankly, we should probably consider this a bug and get it fixed. I
_think_ it's actually fixed in rpm-4_4, so we should be able to backport
it and fix this. Actually, it's apparently even fixed in 4.3.3 (move
global /var/lock/rpm/transaction to dbpath in CHANGES)
>From what I can think breaking up the build system into:
- something that watches cvs for things to be built
One thing that comes to my mind is that you probably don't want to be
watching CVS. Having it be an explicit "request a build now" makes more
sense (which can then be integrated as a makefile target eventually,
etc). I just tend to prefer having "do a build" be an explicit action
rather than a side effect.
- something that makes/handles/cleans up the chroots
Yes.
- something that spawns the builds
- something that deals with the results
These two are likely to be fairly related. Perhaps even the same thing.
Is it reasonable to focus on these as modules to be developed?
The two big things are probably the "handle chroots" piece and "spawn
builds". Especially if we want to go the route of a new chroot for
every build. So I'd mostly focus on those two first and I think the
other stuff will mostly fall out on its own.
Jeremy