[Buildd-tools-devel] Bug#500746: Bug#500746: feature request: use pre-existing schroot or run early script hook

[Roger Leigh]

On Wed, Oct 01, 2008 at 09:49:48AM -0700, Kees Cook wrote:
> On Wed, Oct 01, 2008 at 05:11:23PM +0100, Roger Leigh wrote:
> > Could you possibly explain what exactly you would like to do with this
> > feature?  I would be happy to add some general mechanism to sbuild,
> > such as your patch, but I'd just like to understand the use case for it.
> 
> Certainly.  While I use sbuild for doing Debian builds, I tend to use it
> much more for Ubuntu builds.  Ubuntu has four components, defined in a
> grid based on their freeness and commercial-supported-ness:
> 
>               supported    unsupported
> free          "main"       "universe"
> non-free     "restricted"  "multiverse"
> 
> In order to make sure that Build-Deps aren't satisfied crossing the
> supported/unsupported and the free/non-free lines in the wrong direction,
> I have to modify the source.list in the chroot before sbuild gets
> rolling.

OK, thanks for the explanation.

One easy solution here would be to have a different chroot for each
variant e.g. unstable/main, but of course we need to use the chroot to
get the sources, so this likely isn't viable.

> So, yeah, I'm trying to imagine a general solution, but in this specific
> instance, I need to know the distribution and the source package name
> (from there, I can look up which component the src belongs to, censor
> the sources.list and run apt-get update).

OK.  I think calling external scripts here would be a good idea.  We
could use run-parts to run all the scripts in e.g. /etc/sbuild/setup.d,
for example, in a similar manner to the schroot setup scripts, but with
all of the relevant sbuild state exported in the environment.  This
would make it trivially extensible by users and other packages.

> > Would you prefer to have sbuild call an external program, or would
> > enabling some sort of perl extension system using modules be acceptable?
> 
> A perl extension feels like overkill, and I was thinking that an external
> program (if it had access to enough of the sbuild state environment)
> could be very easy to configure and change by an end user.

Agreed.  If you haven't already, you might be interested in looking at
the current sbuild in git:

  git://git.debian.org/git/buildd-tools/sbuild.git

Here, the main build state, configuration, chroot information etc. have
all been object-oriented using perl objects.  We can easily write a few
lines of perl to dump the object state into the environment so scripts
can access it.  This would only be possible for scalar and perhaps array
values realistically, but it would give you all you need to do what you
want.

This is unreleased; I was aiming to upload this to experimental this
weekend, with unstable following the release of Lenny.  Quite a few more
changes are planned; the object-orientation is just the first step to
getting a number of more significant changes made, including getting
buildd into the Debian packaging and making wanna-build support multiple
database backends, such as SQLite and PostgreSQL.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20081002/ac508b32/attachment.pgp