On 2011-03-02 at 18:52:20 [+0100], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote: [ ... ] > 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. Ah, right, /boot/common/var is another one. Though with respect to the amount of folders that would have to be bind-mounted, there's no difference between Truls' and Stephan's layout suggestion. Stephan has just separated the 'packages' folder from its mountpoint. > > 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. How would packagefs know the user when it is being access from input_server or the net_server? > 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. Damn, those are valid concerns, I guess I got a little carried away by the cool idea ;-) cheers, Oliver