[haiku-development] Re: PM Mount Points
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 18 Feb 2015 10:35:50 +0100
On Wed, Feb 18, 2015 at 08:53:36AM +0000, Simon Taylor wrote:
> Hi all,
>
> Yet another attempt to change the subject to something less troll-like :)
>
> The discussion is now down to where to place the packagefs mount points. I’ve
> attempted to fairly summarize the pros and cons of the competing options,
> along with a name of someone making the argument (non-exhaustive and from
> memory):
>
> Directly in ~/config and /system (as ~/config/bin, ~/config/include,
> /system/bin, etc):
> + PM should be the default for new users, so this seems a more “primary”
> location (Augustin)
> + On a default install ~/system/bin will actually have some things in it (Me)
> - The ~/config and ~/system directories end up with a mix of RO and RW
> directories (Axel)
These are valid arguments.
> + It works like this now (Me)
There wasn't any stable release yet, so this isn't a valid argument.
> - 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,…
We used to have an optional package doing that, it can't be converted to
an HPKG because /boot/beos is outside the package-managed directories.
But a shell script setting up those links is very easy to write. The
script could even use finddir, so it would still work next time we
change the paths again.
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.
>
> Under a separate folder ~/config/packaged/bin, /system/packaged/bin, etc:
> Essentially the opposites of the above points:
> - Less “primary” FS location
> - Would involve some work to change
ok.
> + 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.
> + Less breakage of existing scripts, downloaded zips, easier migration,
> fewer SoftwareValet hacks
>
> For me the winner is clearly a separate “packaged” folder for the stuff
> provided by packages. Yes it’s potentially less “primary” a location, but as
> Augustin said as part of his argument for the status quo “end-users” don’t
> need to care about the actual implementation in terms of the paths. They just
> need to install a package and run the command from terminal or the app from
> deskbar. For power-users and developers I’d argue it’s much more intuitive to
> see all the read-only folders under a specific “packaged” subdirectory, and
> to understand that to change the contents of that folder you alter the
> packages that are installed.
>
> The “BeOS Compatibility” claim can be overstated - already Haiku uses /system
> rather than /beos for example, but in that case a simple symlink can add back
> compatibility. With the status quo PM tries to own folders like /system/bin
> that had previous uses and turns them read-only and exclusively for packages
> so it’s no longer possible for users to set up a compatible hierarchy to
> guarantee pain-free migration.
>
> One possible reason it was done this way when Ingo and Oliver were originally
> developing PM was that any fixed paths used in packaged software would
> continue to work. That was probably an advantage when trying to get the
> packaged system to boot with the shortest amount of development. However now
> we have the situation where packaged software can get away with “broken”
> usage of fixed paths, whereas old scripts, apps and zip distributions simply
> break. Now we have an active set of volunteers maintaining packages it seems
> sensible to switch to the other way around - the active, maintained software
> can be improved to use the appropriate APIs to work in a moved packaged/
> hierarchy, and old scripts and zips will continue to work with their fixed
> paths.
Once again, where are these broken packages? Everyone pretends there are
some but once we ask for specific examples there is never an answer. I
would much prefer if we spent some time repackaging such apps more
cleanly (and we already did a lot of work towards that, in GCI,
haikuports, and haikuarchives). Yes, it is a solution that needs more
work, but it is a good thing in the long term to make sure the software
is maintained. This also helps solve other problems like moving to new
architectures (x86_64 or ARM) and generally keeping the software up to
date (localization, layouting and font sensitivity, and general updates
to be more useful).
So, until there is actual proof that essential software can't be run
anymore because of this path change, and there is no workaround, this
argument is void. The one about keeping things simple for new users by
having a clearly separated read-only directory still stands.
--
Adrien.
Other related posts:
