[buildd-tools-devel] Some schroot (union) fixes

[Jan-Marek Glogowski]

Hi

> The major recent change has been the merging of the union filesystem
> support from Jan-Marek Glogowski.  I'd like to release a development
> version (1.3.0) for further testing once I have confirmation that what
> was merged is working.  Could anyone verify this?  Jan?

The following patches contain my patches on the top of current master.
At least the patches 07-11 are needed to build a package with working
union and sbuild support.

> [aufs appears to cause Oopses on 2.6.30, though it might be an unrelated
> issue since the Oops is in ext4/dquot].  

I'm running the aufs version from git, branch 2.6.30 here, but with a
self-build kernel and some additional patches.

> Chroot Facets
> ------------- 

Generally a good idea. We already added a lot of "base" classes, so the
chroots inherit their "correct" features. I guess virtualisation would
make the whole inheritance tree almost unmanageable. Interfacing the
feature classes (union, source, mountable) helped a bit, but facets look
much simpler to manage.

Do you really want to convert everything before the next release?

> I'd like > to support other types of virtualisation (kvm is my initial
> aim), and this will require modular support for how we run commands,
> since for kvm we can't just do an exec.

AFAIK there are already a few projects, which implement virtual machine
managers for Xen / kvm (virt-manager, xen-tools, ...). How does 
virtualisation fit into the schroot concept? VMs already have the normal
access control from the installed OS.

> schroot client-server protocol using IETF secsh-filexfer protocol
> -----------------------------------------------------------------

...

> A design issue with schroot relating to its origins as a more
> advanced dchroot replacement is that it is a setuid-root program
> which runs in a single shot.

I don't think that's an issue - for me it's a good descition based on the
the requirements.

... <a lot of mor stuff for VM managments (as kind of chroots)>

I'm not using VMs except for testing our distributions installations. I
guess cross-compiling would be easier using a qemu system, then building
a complete cross-compiling chain (when used with sbuild).

So is there a good scenario, where a feature like that would help?

Regards,
Jan-Marek