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.