[buildd-tools-devel] Sbuild configuration environment variables in external commands

[Roger Leigh]

On Thu, Oct 25, 2012 at 01:35:35PM -0400, Jonathan Reed wrote:
> We're migrating our internal build infrastructure from sbuild 0.60.1
> to 0.62.6.  We currently use setup-hook to dynamically generate some
> extra sources.list files in the chroot.  (I see that setup-hook has
> been deprecated, but that's not relevant to my question).  This
> setup-hook in turn relies on some of the sbuild configuration
> environment variables (e.g. SBUILD_BUILD_CONF_DISTRIBUTION).  I'm
> aware of the new changes with build_environment and
> environment_filter, but I still can't figure out how to cause sbuild
> to set these environment variables in the first place. Looking at
> the source, I don't even see how it's possible anymore, since
> there's no longer a call to $self->get_env before running external
> commands.  I can come up with a workaround, but before I waste my
> time, I wanted to confirm whether or not sbuild 0.62.6 is capable of
> passing its current configuration via environment variables to
> external commands or not.  Can someone tell me whether or not that's
> the case?  And if not, how do I reproduce the old behavior of sbuild
> passing its configuration to external commands?

I don't remember that we have ever set the sbuild configuration in
environment variables, unless I have a *very* bad memory.

I'm aware that the existing hook scripts are not ideal.  There are
a number of bugs relating to that.

On my near-term TODO list, I'm planning on converting the existing
logic in Sbuild::Build, which uses a set of nested method calls
with exception unwinding to handle cleanup into something a bit
more extensible and robust.  I'd like to have each step in the
build in a command object with start/stop methods (similar to the
schroot setup scripts), so that we can invoke the start method in each
in order and call the stop methods in reverse to clean up.  This will
enable us to insert hooks at any point in the sequence, making it
rather more flexible and extensible than what we have at the moment.

We can certainly look at serialising the internal build state into
the environment for use by hook scripts.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800