On Sun, Jul 05, 2009 at 03:07:58PM +0200, Stefano Zacchiroli wrote: > On Sun, Jul 05, 2009 at 01:26:23PM +0200, Tollef Fog Heen wrote: > > ]] Yannick > > > > | For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 > > | Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript > > | engine). With ia32-apt-get, I could install the 32bit version of my > > | GTK theme engine so that Firefox can look good. > > > > You could just use a chroot. It's not that hard. > > Oh come on, this is really a non-argument. Here we are trying to build > a system that can be used by random users, not developers (like > probably all of the people reading this thread) with half dozen > entries in their schroot.conf.
The fact that schroot was primarily written for developers does not make it any less useful for ordinary users. The current version has features such as /etc/schroot/chroot.d which are intended to allow other programs or packages to drop chroot definitions in there. This was done with the intent that someone could write a simple script to create a chroot, drop an automatically generated configuration in there, and it will Just Workâ˘. The existing setup will by default set up /home, /tmp etc. as on the host system, so for most users, it will appear completely transparent. If you look at the sbuild-createchroot script in sbuild, which is a wrapper around debootstrap to set up a buildd chroot, you'll see that it does just this. While I don't personally have the time or inclination to write a user-centric script, such a script could very easily be written to allow such use. TBH, users can just use the existing script, with perhaps some additions to install what they need. As I see it, there are two major hurdles: 1) Initial creation of the chroot. As above, I think a simple script to integrate with the existing tools would work just fine here. 2) An easy way to run programs inside the chroot. This depends upon exactly what you want to do. Wrapper scripts or shell aliases do a good job for existing users; automatically generated desktop menu files for specific applications would also work. While I agree that chroots do appear more technical and fiddly to set up, the reality is that we now have the means to set them up in a reliable and automated fashion, and this will give the user a more robust environment than a monolithic library package set from a security POV, as well as giving them access to the /entire/ archive rather than a restricted subset, making it rather more useful. While multiarch should solve this problem, chroots offer rather more functionality and reliability at the present time, with a (rather small) hurdle to set up initially. 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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
