[haiku-development] Re: Question about /system and /boot/system
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 02 Mar 2011 18:54:16 +0100
On 2011-03-02 at 18:12:32 [+0100], Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> On 2011-03-02 at 15:49:51 [+0100], Stephan Aßmus <superstippi@xxxxxx> wrote:
> >
> > Perfectly valid. To be honest, I was concerned about how to manually
> > install software without involving packages, especially during
> > development. I just don't understand from the above how it would work
> > exactly. I thought bind-mounting package-fs in a folder hides what
> > contents that folder has on the real FS. I don't know at all if this
> > might be helpful, or how it relates to testing software without making a
> > package first, but I just had the idea to make a folder layout like this:
> >
> > boot
> > +-packages
> > | +-system (system packages)
> > | +-common (common packages)
> > +-system (bind mount point for system packages)
> > +-common (bind mount point for common packages)
> > That would leave the current layout totally intact, though the placement
> > of packages outside of system or common kind of violates the inherited
> > purpose of these folders. I don't know how user provided packages come
> > into place.
>
> 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 see the beauty in the read-only part. On the other hand I don't know
whether I like that stuff that belongs to "system" or "common" would be
distributed over three different top-level folders (instead of each category
having its own top-level folder) and the user directories working differently.
> > But I have an even better idea: In theory, it would be coold to overlay
> > all package-fs contents in a single file system tree. Right now, we sort
> > of manually re-implement the "path resolving priorities" at various
> > places. For example the PATH environment variable does it, but also many
> > servers, for example the media_addon_server, manually implements
> > resolving and shadowing add-ons in user/common/system paths. It would be
> > cool if there would be only one package-fs mount point, and one could
> > give the package-fs three locations to read packages from, whereas
> > overlapping package content takes precedence according to the
> > user/common/system priorities. Think of it this way: The system folder
> > used to be "don't touch", while in fact it's now "system/packages",
> > which is don't touch, and the rest of file system tree is actually
> > virtualized/read-only anyway. So it might as well be one virtualized
> > file system tree for software installations, which is composed from
> > three different package content locations (i.e. there will only be the
> > system hierarchy left). Am I making sense?
>
> Wow, now we're talking! ;-) Yes, you do make a lot of sense. Packagefs
> already allows for the mounting of several package folders into one
> hierarchy, too (that just can't be requested via mount currently).
>
> 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).
[...]
> > IIRC, the package-fs already has to deal with overlapping package
> > contents, for when packages place the same file in some location.
> > Basically, it would only have to employ the shadowing algorithm. For
> > example if a package in packages/common shadows
> > system/add-ons/media/plugins/ffmpeg, and that package is removed, it
> > unshadows the same file exported by a package in packages/system. All
> > package-fs has to do is generate a node monitor event that the file has
> > changed, which would trigger media_addon_server to reinstantiate the
> > plugin. I would find that much more elegant than the current approach.
>
> Yes, it surely is very elegant.
>
> > One more idea: To solve the problem that one may want to install a
> > self-compiled library as a user, one could still have the current
> > home/config/lib and all the rest, exactly as it works right now. That
> > has nothing to do with the fact that user installed packages would
> > appear in /boot/system, but only that one can still override/install
> > some software without involving packages at all (no changes to all
> > existing software would be necessary, but it would not allow to remove
> > manual dealing with the shading from all software completely, only the
> > dealing with common/* could be removed).
Which essentially kills the whole advantage. Whether monitoring and shadowing
for 2 or for 3 directories has to be implemented really doesn't make much of
a difference.
> Yes again, keeping the current folder structure in /boot/home/config for
> unpackaged software is probably the most elegant solution available.
>
> I like the whole morphing idea so much that I wonder if there isn't a way to
> get it working for multiple concurrent users, too?
I'm a bit confused. Actually that was my very vision (though not fully
implemented) when I wrote the initial packagefs. The idea was to associate
each user's package domain (IIRC you renamed the term) with the respective
user's ID and only make it visible to processes with that UID. I thought you
explicitly decided against that approach. And you actually convinced me that
mounting three separate packagefs instances (or rather 2 + n) would be
preferrable anyway.
* The main reason I found the original idea so interesting was that a package
would believe that it was installed in the same location regardless of
whether it was installed system-wide (i.e. in "common") or only for one user.
This would avoid trouble with ported software packages that hard-coded
absolute paths. Though, as you argumented, there are Linux distributions (or
rather package management solution) that have apparently already solved that
issue as they allow per-user installations.
* Obviously the showing/hiding of packages on a per-UID basis is
significantly more complex to implement (unlike the alternative, which is
already usable). We might also run into problems with it, like singleton
server processes running as root (or some dedicated user) not seeing per-user
files (e.g. app-server and user-locally installed fonts). Or seteuid()
programs being confused by a changing environment.
* When all is merged into one location, it will be non-trivial to determine
where a certain file comes from. That would also make it complicated e.g. to
prevent a "system" program from being dynamically linked against a user-local
library when started by a user.
CU, Ingo
Other related posts:
