[haiku-development] Re: Question about /system and /boot/system

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.

Other related posts: