-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
With a slightly nobbled version of multistrap, would something like this
be usable for hooks?
I: Calculating obsolete packages
Using directory /tmp/multihooks/ for unpacking operations
I: Extracting gcc-4.4-base_4.4.5-10_amd64.deb...
I: Extracting libc-bin_2.11.2-10_amd64.deb...
-> Processing conffiles for libc-bin
I: Unpacking complete.
I: Running 1 post-download hook
I: Running post-download hook: 'download-test.sh'
/home/neil/hooks/download-test.sh was passed /tmp/multihooks/
I: dpkg configuration settings:
DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true
LC_ALL=C LANGUAGE=C LANG=C
I: Native mode - configuring unpacked packages . . .
I: Starting 1 native hook
I: Starting native hook: 'native-test.sh'
/home/neil/hooks/native-test.sh was passed /tmp/multihooks/ in startmode
I: Running preinst scripts with 'install' argument.
dpkg --configure -a ... would happen here
and the reinstall stage here
I: Stopping 1 native hook
I: Stopping native hook: 'native-test.sh'
/home/neil/hooks/native-test.sh was passed /tmp/multihooks/ in end mode
I: Tidying up apt cache and list data.
extrapackages stage would happen here - with another call to the native
hooks for configuration of those packages.
I: Tidying up apt cache and list data.
I: Running 1 post-configuration hook
I: Running post-configuration hook: 'completion00.sh'
/home/neil/hooks/completion00.sh was passed /tmp/multihooks/
Multistrap system installed successfully in /tmp/multihooks/.
The current documentation for this process is:
If a hook directory is specified in the General section of the
"multistrap" configuration file, the hook scripts which are executable
will be run from outside the multistrap directory at the following
stages:
download hooks
Executed before unpacking is started, immediately after the packages
have been downloaded. Download hooks are executable scripts in the
specified hook directory with a filename beginning with 'download'.
native hooks
Native hook scripts are executed only in native mode, immediately
before starting the configuration of the downloaded packages and again
upon completion of the package configuration. Native hooks will be
called the absolute path and the current progress state, start or end.
Native scripts are executable scripts in the specified hook directory
with a filename beginning with 'native'.
completion hooks
Executed immediately before the tarball is created or "multistrap"
exits if not configured to create a tarball.
Completion scripts are executable scripts in the specified hook
directory with a filename beginning with "completion".
Hooks are passed the absolute path to the directory which will be the
top level directory of the chroot or multistrap system. Hooks which
cannot be resolved using realpath or which are not executable will be
ignored.
All hooks of one type are sorted into alphabetical order before being
run.
Note that "multistrap" does not rollback the effects of hooks in the
case of errors.
The test hooks themselves were just:
#!/bin/sh
echo $0 was passed $1 $2
etc.
The relevant configuration file is something like:
[General]
arch=
directory=
# same as --tidy-up option if set to true
cleanup=true
# same as --no-auth option if set to true
# keyring packages listed in each debootstrap will
# still be installed.
noauth=false
# whether to add the /suite to be explicit about where apt
# needs to look for packages. Default is false.
explicitsuite=false
hookdir=/home/neil/hooks
# extract all downloaded archives (default is true)
unpack=true
# the order of sections is not important.
# the debootstrap option determines which repository
# is used to calculate the list of Priority: required packages.
debootstrap=Debian
aptsources=Debian
[Debian]
packages=apt
source=http://ftp.uk.debian.org/debian
keyring=debian-archive-keyring
suite=wheezy
The new line is:
hookdir=/home/neil/hooks
$ ls /home/neil/hooks/
completion00.sh download-test.sh native-test.sh
Let me know how this looks.
Multistrap is now getting as complex as I think it can support.
machine:variant support can be replaced, over time, with hook
functionality but that's about it. Anything else will have to be a new
package which uses the hooks. (Thinking that the cross-chroot stuff
should migrate into pdebuild-cross too.)
I now need to make a call for new translations but I'll do that once
this version hits unstable. It can then migrate into wheezy before the
next upload to add the translations.
- --
Neil Williams
=============
http://www.linux.codehelp.co.uk/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNUCfIAAoJEPFn5DyBQ7aCTqAP/2YVnwALVn1uU5hwHD3aTn8x
oxzMTdlwyKvPp391qamYm5GA9L0nsieav/3YYiRnqFMaE/ZTYzdKMQT4QOCsXUxz
Y+AdpnxduUce0VJ77RawPGKpJDPS81yZJ1er83ES6uEy6Rrygxf0FDtrpQdpR2b6
W3jV/IUrSS/yO8tPYaQyW71zGy5SAJ3T9Da0OgWsPaC45Atyc6+oG5tKXR9A+nU1
rn1yMoWokNO71VyovNHsFzZDGxipnDoTwM4hGrr3NXdn4nk3LaHEy6dQehK0hznQ
rynF8mOuM0Y9+gyAgqmWyyc1htP+pt11bQjMnMozN2qtPdFMSFnk3qULui2+G+Xs
pB84iIRNjUPHJZcuKVEwlhrXtCJwIfxyAF2cqhCrNwsEkpFEwBKgqDNvhSVc9vrf
pDgEz5HPKgEjC/iM66WkX5Pa92x/cTzmKhaMOUmVSORdicTJLjqbXYmzqLgTQjht
+FfSl8XhukNLFoveznQ3nCsECRku3MOaQAlWYXU0UKVN5cceYnaXxxgvj+wLDIKK
w+himiMMNyEbwhDF78fzuHOVe2WYsBEHmcWqWx5+2enA8IllV+HBJziQU/q+I5fI
Ms7WuIWHCm6yOyqRroToBosORtIKARr8EJNEzjxaxMUUBrY2oUWifs6KLWpSht72
hGvuL3d778TbEBuqxqQo
=t7p+
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
