[Buildd-tools-devel] sbuild --auto-give-back / sbuild<>wanna-build interaction

[Florian Lohoff]

On Tue, Jan 08, 2008 at 09:25:13PM +0000, Roger Leigh wrote:
> That's because it is a GDBM database using the horrific MLDBM frontend
> (multi-level-hash in flat file).  The performance is awful, because
> it's basically munging what should be several relations in a proper
> relational database into a single flat file.
> 
> I would like to make the wanna-build data storage backend
> configurable, with at least sqlite and postgres as options in addition
> to the existing GDBM format.  The would allow us to use several
> tables, including storage of the build statistics and fast and easy
> queries with proper joins.  It can even store multiple distributions
> and architectures without much penalty.
> 
> I originally proposed this to Ryan Murray well over five years ago,
> but he strongly disagreed with this.  His rationale was that
> wanna-build/buildd/sbuild should have minimal dependencies in order to
> allow bootstrapping new architectures--which is fair enough.  However,
> there's no reason that the more advanced backends couldn't be
> /optional/ so as to still allow initial bootstrapping with a less
> functional backend.

The point here is that sbuild and buildd need to run native whereas
wanna-build is typically running somewhere else. So i dont see a 
dependency as a problem for bootstrapping here. 

> There's no reason that the rare need to bootstrap

I know the pain of bootstrapping myself - Done it for mips and mipsel
and its a pain in the ass but in the end there were much more 
anoying dependencies (circular build dependencies e.g. XFree and groff)

One of the dependencies i am more worried about is that the buildd
runs the native apt with config and databases within the chroot.
In case of the mips bootstrap this would have failed as the native
installation was a VERY outdated hardhat installation.

An interesting thing would be to be able to run a buildd on anything
linux like as long as the chroot is a debian.

> If you are interested in working on any of the above, I'm sure your
> contributions will be most welcome.  While you can of course clone the
> git repo to work for the time being, we can add you to the
> buildd-tools Alioth project, giving you write access to the master GIT
> repo, so you can push changes into it directly.  I'd like to review
> the first few patches first, though--it's currently a fairly hairly
> codebase.

I am following the codebase via git already but i am happy sending
patches as is - not feeling too comfortable with the codebase so
reviewing is a good thing ;)

Flo
-- 
Florian Lohoff                  flo at rfc822.org             +49-171-2280134
	Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20080109/62c01240/attachment.pgp