No subject

stuff into source. Maybe we can't think of "good" examples for the
combination of lvm-snapshot or file and fs-union. Maybe it wouldn't be
useful with default combination, but someone can add a completely custom
branch definition, with multiple rw branches to store central logfile in a
second rw branch (which could also be done via mount-defaults), but even
if layering doesn't make much sense, it should not hurd (exept for the
branch change outside of union crash, which might not be valid anymore -
it was just a BUG in the unionfs 1.4 manpage).

Next time I'll export my git-tree on my homepage, so you can clone my
branch from there, or should I send more patches to this list?

> Other minor suggestions/questions:
>
> Should mount not be called with -p ?

??? man mount: "-p num" If the mount requires a passphrase to be entered,
read it from file descriptor num instead of from the terminal.

> Is it our place to modprobe kernel modules?  Or, should be admin load
> the modules specifically?

The script just tries to modprobe the fs-module, if it can't find it in
/proc/filesystems. I can add a flag "auto-modprobe", but on the other hand
its possible to explicitly select the fs to try for every chroot
(fs-type). For me its convenience for non-root users and I don't have to
add explicit loading to /etc/modules after a reboot.

> Why does gettextize need adding to bootstrap?  We already call
> autopoint to set it up.  Also, why does the gettext version change in
> configure.ac?--through I have no objection to using a later version.

On my first checkout I didn't saw the bootstrap file and calling auto* was
missing some stuff. Maybe it's not needed anymore. I really don't care
about the gettext version.

> debian/control: We can't downgrade the boost version to build in
> unstable, so I can't apply that part.

Oh that's ok - I'm using Debian Etch and Ubuntu Gutsy. I've read the
changelog comment about changeing the version because of the boost library
renames. schroot builds on Etch without any problems with these lowered
dependencies.

> overlay_base: While a temporary directory is OK, we also need to
> consider that the sessions should (by default) get preserved over a
> reboot.  As a result, we might want to create /var/lib/schroot/overlay
> for the purpose.  If having it on a tmpfs is important, we can allow
> the user to customise this in schroot.conf.

Preserving the session should work, as long as the branch inodes didn't
change. Not sure what happens, if the unions virtual inodes wouldn't match
the real inodes anymore...

> This is what I came up with with a brief review--I'll have a more
> detailed look later on.  Again, many thanks for taking the time to do
> this!

So my TODOs:

- I'll split the patch and move my "Etch control and bootstrap" into a
  second patch and also remove the uneeded configure.ac changes.
- I'll merge the "fs-union" code into the chroot_source, as I can't think
  of any impossible combination. This will add the "fs-union-type" "none"
  as a default, so we won't have union overlays as default.

The only missing piece of the plan is the "moment", when the union is
mounted. Currently it's before any other mount but this won't work with
lvm, which will cover the whole unionfs.

Probably we can mark mounts before and after union? An other idea would be
to mount everything ro before union, everything rw after. As for fstab,
default would be rw, but this - again won't work with lvm-snapshot...
Any idea for a good solution?

Jan-Marek