[haiku-development] Removing /boot/common
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 22 Sep 2013 02:05:53 +0200
Howdy,
I'd like to suggest the removal of the /boot/common hierarchy. We
originally introduced it as a place where software could be installed
globally, while /boot/system would contain a completely read-only,
self-contained base system. Even if something broke in common, one would
still be able to boot into the base system via a boot loader safe mode
option. (I believe that was never implemented.)
Due to the base system being unusable (or not even working) without
quite a few of third party packages and optional packages only being
installable in common, we actually haven't had a self-contained system
so far. With the introduction of package management, we enforce the
self-containedness of system at the package dependency level (the
package set in system is closed wrt. to the package "requires"
relation). This pulled quite a few packages to system. The alpha release
image contains more packages in system than in common, which will shift
even more in that direction as we're outsourcing more of the software
that currently lives in the Haiku source tree.
Since there can be certain dependencies between packages (e.g. relative
symbolic links or built-in relative paths) -- usually in case when
software belonging to a single port is broken up into different packages
(e.g. there are 6 git packages) -- certain packages must be installed in
the same location as other packages. That means that a package that
depends in such a way on another package (we call base package) that
lives in system either has to be installed in system as well or the base
package has to be copied to common first. The former further blurs the
distinction between system and common, the latter isn't nice either.
Another problem is that system doesn't have writable directories
(settings, var, cache). Software installed in system uses the same
directories as software in common (/boot/common/{settings,var,cache}).
Since we want to allow different versions of the same software to be
installed in different installation locations, this poses a problem in
case of incompatibilities between the different versions.
Getting rid of /boot/common -- or rather merging it into system -- would
simplify things quite a bit. We'd lose the self-contained base system
hierarchy, but we don't really have that anyway.
Instead of the safe mode option to boot into the base system in case of
problems package management can offer an equally useful alternative:
When packages are uninstalled or replaced, we already back the old
packages up in an old-state directory. This is done in anticipation of a
to-be-introduced boot loader feature to boot into such an old state of
Haiku.
Furthermore, since packages that require global settings/configuration
files contain defaults for those, another boot loader option could be
introduced to overlay the modified settings with the defaults. This
would help in situations where a change in a global configuration file
breaks something fundamental (like the shell).
I don't expect a lot of problems due to removing /boot/common. BeOS
never had it, so old software wouldn't mind. Anything newer should use
find_directory(). There are a few packages that hard-code common paths
-- e.g. in search path lists (gcc, cmake) -- but that can be remedied
and mostly doesn't have negative effects anyway. We have already aligned
the internal layout of all installation locations, so that there
shouldn't be any surprises in that department either.
Thoughts, suggestions, flames,...?
CU, Ingo
Other related posts:
