[haiku-development] Re: Question about /system and /boot/system
- From: Truls Becken <truls.becken@xxxxxxxxx>
- To: Stephan Aßmus <superstippi@xxxxxx>
- Date: Wed, 2 Mar 2011 18:20:00 +0100
On 2011-03-02, at 15:49, Stephan Aßmus wrote:
> 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.
>
> 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? The new layout would like this:
>
> boot
> +-packages
> | +-system (system packages)
> | +-common (common packages)
> +-system (bind mount point for package-fs for all packages)
> +-bin
> +-add-ons
> +-servers
> +-...
> +-home
> +-config
> | +-packages (user packages)
> | +-settings
> +-mail
> +-downloads
> +-...
>
> 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.
The idea seems appealing. A few comments:
1) When Haiku goes multi-user, the single package-fs mount point would have to
show different contents for each user.
2) I guess some system files, like the kernel, can't live in packages?
3) It shares some of the confusion potential of union-fs, sans direct
manipulation of files giving unexpected results (since you can't directly
manipulate the files). It might help to show full path to the hpkg in an
attribute on each file.
Yes, the package-fs needs to deal with collusions anyway, but they should
happen rarely (a linux-style package manager would refuse to install colliding
packages, but since there is no install step with the Haiku package manager,
that's not an option)
4) Ryan indicated that the system files should be in a single package (updated
with binary diffs). I don't know if this is the consensus, but if so, it
wouldn't make sense to put it in its own directory. You could simply have
/boot/packages contain both the common packages and the read-only haiku_r1.hpkg
or core_system.hpkg.
5) It just occurred to me: /boot/system was not there on BeOS, was it? Wasn't
it /boot/beos, but had a subdirectory called system? (And perhaps it had a
symlink /system -> /boot/beos/system, Ingo?)
-Truls
Other related posts:
