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

  • From: Truls Becken <truls.becken@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 2 Mar 2011 11:50:39 +0100

On 2011-03-02, at 10:45, Oliver Tappe wrote:

> On 2011-03-02 at 00:04, Truls Becken wrote:
> 
>> 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.
>> 
>> As far as I can see, it has these (dis)advantages:
>> 
>> + Good for backward compatibility
>> + 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.

Yes, this basically means switching the primary (/boot/common) and secondary 
(/boot/common/something) folders. Instead of /boot/common/packages/contents you 
have /boot/common/legacy as secondary. This is a good thing for /boot/system 
since the legacy part would not exist there.

You get the same need for a legacy folder with the symlinks Ingo mentioned, btw.

I should add another disadvantage to the list, though: The set of "real" 
folders needs to be decided up front since they are effectively banned for use 
in packages. Or you could say that there is a list of folders that are ok in 
packages, and any others are not guaranteed to work.

-Truls

Other related posts: