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

[Roger Leigh]

Kees Cook wrote:
> Hi Roger,
> 
> On Thu, Oct 02, 2008 at 12:36:34AM +0100, Roger Leigh wrote:
>> 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.
> 
> I'm finally getting back to looking at this.  It does seem likely that
> system-wide setup scripts could be good, but I'm not sure the specific
> use-case I'm after would really be done here (for example, I don't want to
> do this for Debian builds, only Ubuntu builds).  It doesn't seem right to
> make those choices in /etc/sbuild/setup.d/something is the right place --
> i.e. it should really be up to the sbuild invoker.

You could use a conditional in the script so that you only do it
for specific builds (for example, based on the chroot name or the
contents of /etc/debian_version inside the chroot).

We do a similar thing for chroot type-specific code in the schroot setup 
scripts; the scripts are all always executed, but only the necessary 
bits are actually used.

>> 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.
> 
> Where should this happen?  My particular use-case seems to need details
> from both $build and $options.  Should exec_command export all of those
> values into the environment in addition to the stuff listed in
> Defaults->ENV?  SBUILD_BUILD_...  and SBUILD_OPTION_...  ?

If we want to do this for every command we run, then yes.  However, it's 
also possible to set it specifically for a single invocation with 
ENV=>{env} in your command.  So you could, for example, do:

     my $status = $self->get('Session')->run_command(
	{ COMMAND => [$self->get_conf('RUN_PARTS'), $scriptdir, @args],
	  ENV => {environment},
	  USER => 'root',
	  CHROOT => 1,
	  PRIORITY => 0,
	  DIR => '/' });

It will be quite simple to export the scalar and array elements of the 
Build and Options classes, since both are just hashes internally.  I 
think SBUILD_BUILD_* and SBUILD_OPTION_* as you suggest above would be 
ideal names for the environment.

> I've updated the patch (untested...) to use all the new calling conventions
> in git, just for reference...

Thanks, I'll take a look soon.


Regards,
Roger