[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ia32-libs{-tools}, multiarch, squeeze

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.


  .''`.  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.

Reply to: