Bug#329403: [Buildd-tools-devel] Bug#329403: schroot: Clobbers files in the chroot without warning

[Daniel Jacobowitz]

On Sun, Sep 25, 2005 at 08:28:52PM +0100, Roger Leigh wrote:
> >>   - /etc/schroot/setup.d   Scripts used to create, set up and destroy
> >>                            chroots (same as existing scheme).  Run
> >>                            once during chroot setup, and once during
> >>                            teardown.
> >>   - /etc/schroot/session.d Scripts run on chroot entry and exit to do
> >>                            additional setup/cleanup.  These may be run
> >>                            multiple times during the chroot lifetime.

...

> For LVM snapshots, the "lifetime" is the time the chroot exists, from
> initial chroot creation through to destruction.  During that period,
> schroot may be run many times, specifying an existing session to
> restore.  It will work like this:

I think you need to rename your directories and review the terminology
a little bit... if you want scripts to run at the entry and exit of a
chroot, but you call a reused chroot a "session", then it's not clear
whether "setting up the session" happens once or multiple times.

> $ SESSION=$(schroot --begin-session --chroot=unstable)
> [LVM snapshot created, session key stored in $SESSION]
> $ echo $SESSION
> 08903913-2599-4bb3-b555-6ac99bae3793
> $ schroot --run-session=$SESSION "command1"
> [Run command in an existing chroot session]
> $ schroot --run-session=$SESSION "command2"
> $ schroot --run-session=$SESSION "command3"
> $ schroot --run-session=$SESSION "command4"
> $ schroot --end-session=$SESSION
> [Finally end the session, deleting the LVM snapshot]
> 
> For normal chroots, the session exists only for the lifetime of the
> schroot process.
> 
> This is only needed because sbuild is written in Perl.  If I could
> move the necessary parts into C code, it could all run in one process,
> and handle the session management internally.  I've written schroot
> with this in mind (the core objects could be moved into a library).
> In the meantime, this is to integrate with the existing sbuild code.

I'm not sure this makes any sense.  I've written a fair amount of Perl
in my life, and there's very little if anything that you can't do
because something is perl rather than C.  But you're writing the code,
and this is all a bit off topic for the original bug report :-)

-- 
Daniel Jacobowitz
CodeSourcery, LLC