On Sun, Nov 21, 2010 at 08:41:09PM +0100, Loïc Minier wrote: > On Sun, Nov 21, 2010, Roger Leigh wrote: > > 1) It's not checking if $system_arch == $chroot_arch for all > > arches, just a limited hardcoded set; it should probably > > exit 0 if the above condition is true before looking for > > specific pairings. > > Ah right, I initially wanted to do this as I thought I'd add support > for more arches, then I added support for more arches and forgot to > update it, exactly as expected :) > > I'm attaching an updated version which does just that, with a note that > more biarch cases should be added
Thanks. > > 2) The licence is not the same as the schroot packages, which is > > GPLv3+. Would it be OK to have this licenced at GPLv2+ or 3+ > > for compatibility with the rest of the package? > > Yeah; it's just my boilerplate "public domain"-ish snippet, which > includes permission to sublicense. You're welcome to change the > license to GPLv3+ when merging into schroot; you could also keep it as > is and claim that schroot is distributed under GPLv3+. (I'm keeping my > local scripts under this permissive licensing because I'm copy-pasting > shell snippets I write across scripts and projects.) Thanks. > > 3) It would be nice to have a configuration in the script-config > > file to disable support completely, enable it unconditionally, > > or enable for selected architectures as at present. > > Ok; I wanted to add this support at some point anyway > > I'll look at adding this > > > > # - allow setting the qemu interpreter in the script-config file > > > # - allow forcing use of qemu even when not particularly needed > > > # - test support for all architectures > > > # - add support for more architectures > > > > Setting in script-config will require writing a chroot facet object, > > which is something I'd really like to see support for. I'm > > especially interested in support for kvm and qemu-kvm and qemu, so > > these would all fit under the same umbrella. > > > > Currently, we do require that the guest is a chrooted filesystem, > > but I'd like to abstract that to allow running commands in entirely > > isolated virtual systems such as kvm. > > Awesome! I guess remote machines, or cloud/EC2 vms come to mind as > well > > It might make sense to look into libvirt for this Yes, it's one of the things I should really investigate more, since I don't want to duplicate existing functionality unless it's really necessary. Thanks for the updated patch. I'm afraid that it can't go into schroot 1.4 just at the moment due to the squeeze freeze. But I'll put in onto the master branch when I have some free time, and it can go into schroot 1.5/1.6 for wheezy/unstable once the freeze is over. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
