Martin Michlmayr <[EMAIL PROTECTED]> writes: > Let's CC the schroot maintainer. Maybe he can comment whether there's > any advantage to add schroot support to piuparts or whether I'm just > wrong.
I'm naturally somewhat biased in favour of schroot, but I'll try to be objective :) If you are currently using pbuilder, it is, IIRC, simply unpacking a tarball each time you want to use a chroot. You can, if you wish, also do this with schroot, plus a lot more. Just as a simple example, here are the timings for lvm-snapshot compared to file chroots: $ schroot -i -c sid-file -c testsnap --- Chroot --- Name sid-file Description Debian sid snapshot Type file Priority 3 Groups sbuild root Root Groups root sbuild Aliases Run Setup Scripts true Run Execution Scripts true Session Managed true File /home/sid.tar.gz --- Chroot --- Name testsnap Description Debian test snapshot Type lvm-snapshot Priority 3 Groups sbuild root Root Groups root sbuild Aliases Run Setup Scripts true Run Execution Scripts true Session Managed true Location /chroot/sid Path /chroot/sid Device /dev/hda_vg/testpath Mount Options -o atime,async,user_xattr LVM Snapshot Options --size 2G -c 128 $ time schroot -c testsnap -- true I: [testsnap-9b08471c-a0d8-49be-8b94-fd0d6f31cd6c chroot] Running command: “true” real 0m2.206s user 0m0.172s sys 0m0.320s $ time schroot -c sid-file -- true I: [sid-file-a54a4ca5-1d0f-4418-86e6-040dd3e2ac46 chroot] Running command: “true” real 0m16.867s user 0m3.916s sys 0m3.124s In both cases the chroot is a sid buildd chroot with almost identical contents. schroot is simply a means of accessing, and managing, chroots. You have chroot "sources", which can be different things: - directories - files - block devices - LVM snapshots schroot provides a uniform way of accessing these, and hides this so that you don't need to be aware of the differences. For example, it can automatically unpack a .tar.gz or .zip, or create and mount an LVM snapshot, or mount a block device. This is modular and extensible. If there are any other chroot sources you would like adding, it's just a matter of adding a new class to specify the configuration options, and adding a shell script to setup.d to set it up. When you want to access a chroot, a few things happen: - the chroot is set up by running all of the scripts in /etc/schroot/setup.d. These do all the necessary unpacking and mounting. - for each command or shell you run in the chroot, each command in /etc/schroot/exec.d is run. - schroot then chroot()s and runs the command/shell in the chroot - after the command/shell finishes, all the scripts in /etc/schroot/exec.d are run again (with a stop argument) - finally, the chroot is cleaned up (umounted, etc.) by running all the scripts in /etc/schroot/setup.d (with a stop argument) Because of this separation, it's possible to create "sessions", which are basically throwaway temporary chroots. The chroot types "file" and "lvm-snapshot", which are implicitly copies, all support this. This lets a program create a chroot, then keep it around to run several commands in, and then destroy it. This is what sbuild does, for example. schroot also aids the management of these chroots by providing access to the source block device of an LVM snapshot, and for file chroots allows them to be repacked (not in a release yet). Example: $ session=`schroot -c testsnap --begin-session` $ echo $session testsnap-2c7da0d9-884c-48b4-bd97-adfbb67d7608 $ schroot -i -c $session --- Session --- Name testsnap-2c7da0d9-884c-48b4-bd97-adfbb67d7608 Description Debian test snapshot Type lvm-snapshot Priority 3 Groups sbuild root Root Groups root sbuild Aliases Run Setup Scripts true Run Execution Scripts true Session Managed true Location /chroot/sid Mount Location /var/lib/schroot/mount/testsnap-2c7da0d9-884c-48b4-bd97-adfbb67d7608 Path /var/lib/schroot/mount/testsnap-2c7da0d9-884c-48b4-bd97-adfbb67d7608/chroot/sid Mount Device /dev/hda_vg/testsnap-2c7da0d9-884c-48b4-bd97-adfbb67d7608 Device /dev/hda_vg/testpath Mount Options -o atime,async,user_xattr LVM Snapshot Device /dev/hda_vg/testsnap-2c7da0d9-884c-48b4-bd97-adfbb67d7608 LVM Snapshot Options --size 2G -c 128 $ schroot -c $session -r -- uname -a I: [testsnap-2c7da0d9-884c-48b4-bd97-adfbb67d7608 chroot] Running command: “uname -a” Linux hardknott 2.6.15.4 #24 Sun Feb 12 18:40:11 GMT 2006 ppc GNU/Linux $ schroot -c $session --end-session $ schroot -c $session -r -- uname -a E: testsnap-2c7da0d9-884c-48b4-bd97-adfbb67d7608: No such chroot If you haven't used it yet, it's in unstable, and fairly simple to set up. It has a comprehensive set of manual pages, with examples. The very latest (development) snapshot is here: http://people.debian.org/~rleigh/schroot-0.2.6.tar.bz2 It's about 9 months old now, but has started to get a good deal more usage in the last month or so. This is good, because now it's getting wider usage, a number of small (but annoying) usability bugs have been eliminated. While it's certainly stable enough for serious use, there are a few small rough edges which need polishing off. That said, it's now essentially feature-complete (for what I need it for), and my main goals for the next few weeks are mainly usability work; if you look at the open bugs, you'll see what's going on. I'm quite happy to accommodate any changes you might want to integrate better with piuparts needs. If you have a look at the source, all the chroot handling is in schroot/sbuild-*.(cc|h). I could make this available in library form if you wanted to use it in piuparts directly, though it's not yet at the point where I can guarantee full API stability. The main advantage of schroot is that you give the user a choice of which chroot type they want to use, based on their needs for disk space and speed. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linux http://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
pgpDfSoiQMPLY.pgp
Description: PGP signature
