[haiku-development] Re: alpha release window ?

  • From: Brecht Machiels <brecht@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 11 Aug 2009 09:40:10 +0200

Axel Dörfler wrote:
Brecht Machiels <brecht@xxxxxxxxxxx> wrote:
That would work more or less for "common", but not really for the user's config folder - I would consider the need to have an extra directory for this a kludge, at least given our directory structure.
I'm not sure how you would handle the user's config folder. Can you elaborate? I haven't given that part any thought yet.

Not sure what you want me to elaborate about, but the user's config/ folder more or less supersedes /boot/common/ - whatever is found there will be preferred over what's in /boot/common.

Oh right... I was confusing it with the location for storing user preferences (home/config/settings). I'm not quite used to the BeOS directory structure yet, it seems :)

I would have imagined that packages go to special directories, like /
boot/common/packages/ (or even installed_packages) for system wide installations, and ~/config/packages/ for user local installations. The package file system would then show the installed package files either under /boot/common/ or ~/config/, depending on where the package is.

I wouldn't like to join this into a single directory (for the user), and have different views for each user - that would just be like calling for trouble (as the root user should see them all).

But then you would lose the possibility for users to install software locally that depend on absolute paths. I know this should be avoided, but some ports will require that.

I see no major problems in mounting user bundles also under /boot/common. It shouldn't be hard to provide a mechanism for root to show all users' bundle mounts.

On a related note. How do you see Haiku handling multiple versions of a library? If all bundles are mounted under /boot/common, they would need to have a unique namme (libfoo-1.2.3.so). For an application to use a particular version, we would need to virtually link a library into the app's lib search path, as libfoo.so. I hope you agree we don't want to have apps looking for a specific version of a library (libfoo-1.2.3.so)?

For a non-union-FS approach, each lib would be mounted under it's own directory (/boot/bundles/libfoo-1.2.3 or similar) and it's lib directory (/boot/bundles/libfoo-1.2.3/lib) would simply be added to the app's lib search path (based on the bundle's dependency information and which library bundles are installed).

Regards,
Brecht




Other related posts: