On 02.03.2011 10:45, Oliver Tappe wrote:
Hi Truls, On 2011-03-02 at 00:04:11 [+0100], Truls Becken<truls.becken@xxxxxxxxx> wrote:On Tue, Mar 1, 2011 at 20:25, Oliver Tappe wrote:when looking at the restructured folder hierarchy with respect to find_directory(), I have realized that it has become quite a mess :-\ This is the current hierarchy (in the pm branch): [..snip..] For starters, I wonder where /system should point to: currently, /system points to /boot/system, but that folder just contains the 'packages' subfolder. While correct in principle, it means that stuff like /system/bin and /system/add-ons no longer work. I have no idea whether or not that is going to be a problem with many legacy applications and/or scripts.In a thread back in january [1], I made a suggestion about letting /boot/system and /boot/common be both the package-fs mount point and at the same time hold a couple of "real" directories (packages, settings). I don't know if anybody noticed and considered it as an option back then, but it might solve some problems.When you suggested that, I didn't pick up on the notion of just making a few folders "real" in that scenario. I apparently thought you were suggesting a union-fs like approach (which I find problematic because of the awkward "shadowing" effect of written/copied files). But what you mentioned above can be implemented just by letting packagefs automatically bind-mount the "packages" and "settings" folders.As far as I can see, it has these (dis)advantages: + Good for backward compatibility+ Simplifies the conversion of ported software to packages a lot.+ Short (sane) paths to e.g. /boot/system/apps + No need for B_SYSTEM_PACKAGES_CONTENTS - Confusing to have package contents mangled with actual folders - Can't use both package based and manually organized files, as in [2]Yep, we could solve the latter by explicitly providing an 'old-school' or 'legacy' folder (or whatever else would be a good name for it). That could both be used for testing software during development and for installing software that isn't available as hpkg. I personally find the approach of mixing packages with a set of writable folders not very confusing, but quite appealing, actually :-) After all, the settings folder has to be populated from the hpkg-files anyway, so packagefs would have to write outside of its container in the other (current) scenario. And when working on porting the development tools over to the current structure, I did find the long paths quite awkward indeed ... Any opinions? cheers, Oliver P.S.: I know I might be getting on people's nerves with my constant questions about the folder structure, but these are important decisions and changing them around at a later stage (once software has been packaged) would be a lot of work.
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.
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.
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).
Best regards, -Stephan
