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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
