[haiku-development] Re: PM Mount Points
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 19 Feb 2015 10:02:43 +0100
On Thu, Feb 19, 2015 at 12:36:19AM -0800, pete.goodeve@xxxxxxxxxxxx wrote:
> On Wed, Feb 18, 2015 at 03:03:26PM -0800, I wrote:
> > >
> >
> >
> > Let me list what I see as essential for all this.
> > [....]
> > What have I missed?
>
> One thing I realize I missed is the find_directory scheme. I think most of
> it is not affected --
> the B_SYSTEM... set remain read-only, but the B_USER... ones are once again
> all read/write.
> I see, though that '..._NONPACKAGED_..' entries have been added to
> FindDirectory .h.
> Again, the B_SYSTEM_NONPACKAGED... ones are unaffected, but the B_USER... set
> are
> a bit of a paradox.
>
> My suggestion would be to rename them to 'B_USER_PACKAGED...' and have them
> refer
> to the ~/packaged tree. I have doubts that anyone is actually using them
> yet, so it shouldn't
> break much if anything. Alternatively, I guess, the NONPACKAGED set could
> remain and point
> to ~/config, and a new ...PACKAGED_ set could be added. (Lots of room in the
> enum.)
> (The B_COMMON... set depend on whether common is revived or not.)
The "COMMON" set is currently not in the public header, but apps compiled to
use it will still work, they will be redirected to /system/non-packaged.
I don't think there is much use for the NON_PACKAGED constant. During
the PM work we introduced a new BPathFinder class (and C API find_path*)
to search in all possible locations at once. For example you can request
a list of all LIB directories, all ADD-ON directories, all FONTS
directories, etc. This is a more generic and future-proof solution to
enumerating paths. find_directory will stay there, for cases where you
really want to use one specific dir or another.
>
>
> I also wrote:
>
> > At the moment, it looks like settings and other writable files have to be
> > in a (writable) subfolder
> > of the packaged tree, as the manual says the specification (in the
> > .packageinfo) must be a relative
> > path. So there would have to be a ~/packaged/settings and so on. I wonder
> > if it's possible to use
> > absolute paths (or maybe a find_directory based location) to access
> > out-of-tree folders, such as
> > ~/config/settings?
>
> It strikes me, though, that a strategic link or two could easily handle this.
> '~/packaged/settings'
> could just be a fixed link to '~/config/settings', so the user (and the
> package installer) would only
> have to think about the one folder. It might even be nice to have
> '~/config/packages to be a link
> to ~/packaged/packages, so again the user would usually not have to be
> concerned with the
> packaged tree at all.
I would prefer the packages to stay in system and config
(system/packaged or config/packaged as it was suggested earlier).
Top-level directories such as /boot/common or ~/packages are made much
more visible, and they don't need to be there at the FS root or in the
home directory.
--
Adrien.
Other related posts:
