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

[Goswin von Brederlow <goswin-v-b@web.de>]

Roger Leigh <rleigh@codelibre.net> writes:

> On Sun, Jul 05, 2009 at 11:36:31PM +0200, Goswin von Brederlow wrote:
>> Roger Leigh <rleigh@codelibre.net> writes:
>> 
>> > 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, ....
>
> I'm not sure I agree here.  "All possible configurations" is a rather
> impossible goal for any system.
>
> The creator of any package would need to decide what to support by
> default.  It can use the d-i tasks just like a normal installation
> would, but the user will ultimately have the power to configure it
> as they see fit.

That isn't what I ment. Or at least I think you misunderstood.

If the user has configured his sound outside the chroot to for example
use a network sound daemon and play on another host then inside the
chroot the sound should do the same. Or when sound is used outside the
chroot by e.g. kopete to beep when a new message comes in then sound
should still work for a 32bit flash inside the chroot. And so on.

There are a number of things that should be passed from the chroot to
the real system and each has tons of different possibilities for the
user to configure them. Makeing them work out of the box inside the
chroot is shear impossible.

And if the solution doesn't work out of the box but needs lengthly
manual configuration and tinkering then that isn't a solution.

> Although I use amd64, I have yet to want to install any 32bit
> software, so I'm not entirely sure what the use case is for it.  If
> we're talking about specific programs such as proprietary binary-
> only software and browser plugins etc., then we really only need
> the specific software and its dependencies in there.  I really don't
> see the need for an entire functional desktop environment inside the
> chroot, for example.  Some further clarification is needed here.

It doesn't need an entire functional desktop environment, it just
should be entirely functioning. Having a 32bit browser and flash
plugin in a chroot is of little use if you don't have sound while
kopete is running outside the chroot.

>> > 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, ...
>
> These tasks just require the necessary client libraries and/or
> programs to talk to the server.  In the case of the sound, the
> device nodes are shared with the host system, as is SYSV and POSIX SHM.
> For server AF_LOCAL sockets, we can bind mount the sockets in there
> as well.

Yes, you can. It just means do this, and that and that other
thing. And then the user uninstalls sound system A and installs sound
system B and suddenly the old bind mount is inefective since it mounts
the wrong directory.

>> 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?
>
> Well, from a kernel POV, you can certainly use personality(2) to
> switch the execdomain back to PER_LINUX from PER_LINUX32.
>
> You are correct that starting 64bit programs on the host from inside
> the chroot is not possible.  The isolation of the filesystem from the
> host is, of course, the defining feature of a chroot environment.  If
> we are running specific programs inside only, is this a problem in
> practice?

How would you write a frontend so that it ensures any program the
32bit applications might want to start are available? Like cups for
printing. You pretty quickly come to the conclusion that you need to
install every binary in both 64bit and 32bit to be sure.

> It's certainly possible to install schroot inside the chroot and then
> chroot back into a virtual host system, but I do admit that's rather
> gross!
>
>> > 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.
>
> I'd rather see a working multiarch implementation in the long term.  I
> agree that the chroot setup is not as ideal as multiarch, but there are
> quite a lot of people using schroot in practice for this purpose.

We are only talking about NOW. There is no argument that multiatch is
the long term solution. But with >5 years since it was started it
reall is LONG term.

> I would be interested to know exactly why it's not suitable for
> general desktop applications, and exactly what use cases you are
> planning for which lead to this being the case.

As said above. There are too many configuration cases to handle
setting up the chroot automatically and keeping it that way. Too many
things need the users tinkering.

Just ask yourself why we need multiarch instead of a chroot. All the
same reasons apply here. The solution is just not as nice.

> Regards,
> Roger

MfG
        Goswin