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 --