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

[Kees Cook]

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.

So, in the Ubuntu case:
 - src in main:       only main
 - src in restricted: main & restricted
 - src in universe:   main & universe
 - src in multiverse: main, restricted, universe, multiverse

> Are schroot setup scripts not an option, or do you need information
> passing that only sbuild knows about?

The only way I was able to imagine doing it with schroot was to overload
the chroot definitions for each real chroot, defining 5 per chroot, each
having a different setup script.  It seemed like the wrong hack.  :P

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

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

I'm totally open to suggestions -- I just wanted to minimize how much
this feature was getting in the way given that it's primary use-case
is really only useful for Debian derivatives.  :)

> Thanks for the patch.

Heh, it's not very good, mostly just an example of what I was thinking.  :)

Thanks!

-Kees

-- 
Kees Cook                                            @outflux.net