[haiku-development] Re: PM Mount Points
- From: Simon Taylor <simontaylor1@xxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 18 Feb 2015 10:21:45 +0000
>
>> + It works like this now (Me)
>
> There wasn't any stable release yet, so this isn't a valid argument.
It’s a pro of keeping the status quo as any change would require developer
time. It’s perfectly valid.
>
>> - Adds hurdles for users migrating from A4/BeOS (any hardcoded paths in user
>> scripts will break) (Pete)
>> - More workarounds required (rewriting paths for SoftwareValet install
>> scripts) (Me)
>> - ‘Drop here to install’ symlinks broken (Axel)
>> - In the sense of breaking paths and scripts it’s fair to say BeOS
>> compatibility is reduced (our friendly troll)
>
> As you mention below, these 4 were already broken long before PM was
> introduced, since we have already moved the directories in various ways.
> And as you mention, it is still possible to workaround this by creating
> /boot/beos and creating some symlinks there, for example to
> /system/non-packaged/bin,lib,…
There is no equivalent workaround possible for the ~/config hierarchy. And due
to PM owning /system/bin no workaround that would maintain A4->B1
compatibility, which will probably impact more users than BeOS->B1 migrations.
> What it does break is software packaged for older versions of Haiku. But
> we have always been clear about this: Haiku is in alpha state,
> everything can change, no self-compatibility is guaranteed. This is a
> requirement to avoid adding a lot of legacy cruft to the system as we
> go. And we can release a lean and clean R1.
And everyone accepts that. But there’s also no particularly strong reasons for
having PM mounted in the same place that had those well-defined uses pre-PM. So
although breakage is acceptable, if possible it should be minimised.
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.
>> + 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.
> […]
>
> Once again, where are these broken packages?
I don’t think that question is helpful. Yes they could all be fixed, but there
is a solution here that would mean they would just work.
As Pete says, they’re lots of little things scattered around his system.
User-specific scripts, archived zip files, whatever. I don’t think a list is
helpful.
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?
Simon
Other related posts:
