Re: App image experiments

[Colin Walters <walters verbum org>]

On Mon, 2013-02-25 at 17:18 +0100, Alexander Larsson wrote:

>  ./run-merged /opt/base_os/F18 ./nautilus.squashfs

What is the point of constructing the F18 chroot versus just using / ?

> The first one is because of no /etc/passwd i guess.

Because not doing the chroot would obviously fix this.

> The second one is harder. It fails because glib-compile-schemas has not
> run in the merged /usr/share/glib-2.0/schemas where the nautilus rpm put
> it. We need to run the schema compilation and things like that during
> image construction, and probably put it in a different prefix.
>
> Basically, this is where we need to solve the "search path problem".

I think we need something different than that - if I was a system
administrator, I'd like to be able to manipulate and script the settings
for all installed apps.  But that shouldn't involve running them.

So it doesn't make sense to me that each application would have a
compiled schema blob that includes OS + that app.  Rather apps would
have a compiled schema for just their app, and tools like gsettings
would be aware of how to merge in the application data dynamically by
modifying their search path to include the exported schemas.

An obvious primary goal here is that applications should be isolated
from each other, and your solution does do that.

Basically glick2 seems to me to be closer to correct.

> Also, I worry a bit about the loopback mounted files. There is nothing
> prohibiting the user to modify the fs images while the app is running,
> is there? 

chmod o-w ?