Roger Leigh <rleigh@codelibre.net> writes:
> 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.
Which must handle all possible user configurations for mail, sound,
printing, ....
> 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.
Which then can't generaly send mail, play sound nicely (mix with the
non-chroot sound), print documents, ...
And most unsovably: You can not start 64bit programs from inside the
32bit chroot again, have them start 32bit, 64, 32, 64, 32, ... How
many levels bind mounts do you want to do?
> 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.
Not in a way that is suitable for general desktop applications.
And hey, here is this existing way of doing all this so that none of
these problems arise: ia32-apt-get. It also is not monolithic, nor a
security problem and also gives access to the full archive. Initially
it was too much of it even.
> Regards,
> Roger
MfG
Goswin