[haiku-development] Re: PM Mount Points
- From: pete.goodeve@xxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 19 Feb 2015 12:13:48 -0800
On Thu, Feb 19, 2015 at 10:02:43AM +0100, Adrien Destugues wrote:
> 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.)
[Sorry for the long lines. It was late at night, and my attention was
lacking.]
>
> 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.
Ahh. I thought I remembered some discussion about that. Yes,
that works much better for finding the data you want to read.
Seems to me that the main use for find_directory is actually when
you want to *write* something -- you need to put something in the
User Settings folder, say. So getting a read-only pointer back may
not be much help.
> >
> >
> > 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.
Not quite sure what you're saying here, but I don't think we're
disagreeing much.
-- Pete --
Other related posts:
