[haiku-development] Re: PM Mount Points
- From: pete.goodeve@xxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 18 Feb 2015 15:03:26 -0800
Thanks for the new thread title, Simon! (:-))
On Wed, Feb 18, 2015 at 10:21:45AM +0000, Simon Taylor wrote:
> [.....]
>
> If weâre about removing cruft, then surely â~/configâ is a weird name
> for the user-specific root anyway? Perhaps ~/packaged/bin/ etc and /packaged/
> for the system-wide mount point? You can ship a clean, cruft-free image
> without a ~/config/ directory at all, but users are able to create them to
> give an easy migration path. I donât think the breakage (caused by
> redefining existing commonly used paths to be exclusive to PM and RO) is
> justified by strong-enough arguments.
For the user packaged hierarchy, I think that is what I would prefer, too.
Have it parallel to,
rather than a subfolder of, config. I can't really see a need to change
/boot/system as a
mount point.
>
> >> + Entire âpackagedâ folder is RO - more intuitive than a mixture
> >
> > This is not exactly true. Package can provide settings files, which are
> > writable, but partially managed by the PM system (the packaged version
> > can replace the user one, or be merged with it, or the user version of
> > the file is kept - depends on what is declared in the package). Some
> > packages can also have post-install script which will modify writable
> > dirs. So the "packages" folder would influence both "packaged" and the
> > main hierarchy in some way.
>
> I would argue thatâs unintuitive behaviour as well then. Itâs perhaps a
> necessary evil to align PM with the expectations of existing software, but
> dropping a new package into a package folder and having it blindly write or
> modify some files elsewhere feels a bit unexpected to me. Ideally the
> âdefaultsâ should be as part of the package, and user-modifiable settings
> files should be overlaid by the app. I expect post-install scripts also break
> the âprevious statesâ idea somewhat.
>
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?
I think the 'keep-old' etc switches in .packageinfo probably handle most
concerns about
overwriting user stuff.
>
> I wonder how much work it would be to allow users to specify the mount points
> for user and system packagefs use? Then users could at least move them to
> allow pain-free migration. And surely their exact location is just an
> implementation detail?
>
Not sure I see that as being useful. Seems to me that providing a separate
user packaged tree,
and restoring ~/config to R/W is all that's really needed to satisfy everybody.
Let me list what I see as essential for all this.
* In the PackageFS code, change the creation of the "~/config" FS to
"~/packaged" or something.
* Add the necessary paths to SetupEnvironment.
* Remove the special treatment of paths from PackageInstaller.
Maybe also:
* Allow access outside the pakaged tree, if this is currently not allowed
(see above).
I, personally would also like the paths in SetupEnvironment to include the
/boot/common dirs.
What have I missed?
-- Pete --
Other related posts:
