> > 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 whole point of the new app proposal is to run each app in a different runtime environment than the full OS. Each app declares what highlevel requirements it has (bare, gnome-os-1.0, etc) and then it will *only* see that. This separation means you will not accidentaly pull in dependencies that are not supposed to be there and your bundled libs will not conflict with system installed ones. > > 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. This is what i mean by "put it in a different prefix". I.e. you'd build your app in the bundle with a prefix other than /usr, which should let you compile the schemas at *image build* time. This will of course also let us use the system compiled schemas for OS stuff rather than duplicating it. > > 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 ? Thats not really what i mean though. When a user mounts a loopback filesystem the kernel fs code is running, and any change to the file will be done behind the filesystems back. Obviously any data in the page cache will be kept up to date since modifications to the file is done through the kernel, but any other cache on the filesystem level will not see such changes. So, say cached inode info in the kernel may not anymore correspond to what is on disk. Isn't there a risk for exploits and whatnot here? _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
