Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote: > > boot > > +-packages > > | +-system (system packages) > > | +-common (common packages) > > +-system (bind mount point for system packages) > > +-common (bind mount point for common packages) > I like that, it keeps things separate and clear. We just need to > find a > place for the "settings" folder: we either keep it at > /boot/common/settings > (and bind-mount that folder from underneath the 'common' packagefs to > make it > writable) or we could move it elsewhere, maybe /boot/settings? Going > with the > latter would make both /boot/system and /boot/common completely read- > only. I like the "shining through" better, though. /boot/common/cache is also writable, and they might not end up being the only two entries for this. > One problem I can see with that approach though, is that morphing the > user > packages into the /boot/system hierarchy won't work at all when we > allow > multiple concurrent users (unless we implement some very clever > strategies > that allow the VFS to always determine which real user is trying to > access a > path). Since packagefs always knows the current user, it could just change the directory contents on the fly. However, I don't really like that solution that much, as you don't have a clear distinction between your own and system wide packages, let alone how to handle the settings directory in that case. The real problem is that some services must not allow morphing their files, like when you start certain system applications, they should always use the system delivered libraries/settings/whatever instead of what the user wants. Also, it gets pretty messy when you want to find out about configuration problems, as you just don't know what file system a certain user sees (like the root user). I think that idea involves too much magic, and could make the system quite difficult to understand. Bye, Axel.