[haiku-development] Re: Override system file with hpkg
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 01 Feb 2014 13:53:56 +0100
On 02/01/2014 12:14 AM, looncraz wrote:
I've been trying to replace the system Deskbar with my own, but haven't
found a way to make that work.
I tried replacing the one in the haiku-really-long-name.hpkg in
/system/packages but ended up with a bricked install.
You can just put your modified Deskbar in a separate package and install
it in /system/packages. ATM whenever files of different packages clash,
the one with the newer modified date wins. If you intend this as a more
permanent solution -- i.e. update the system while keeping your package
-- you would want to additionally blacklist the system package Deskbar
as Matt mentioned, so it doesn't eventually become newer than its
replacement.
I tried creating
hpkg that imply had /system/Deskbar in it, placed it into
/home/config/packages and verified that it is active... but the main
system Deskbar is still active (which I would hoped/expected would be
the case for security reasons ;-) ).
You notice that this has really nothing to do with PM? Installing a
Deskbar in home didn't work before either. Or the other way around: if
it had worked before, it still would.
I seriously think we need a way to write into the packages
transparently. They can (and should) be loaded as read only by default,
but the system should make it relatively easy to override.
Making the packages themselves modifiable -- or more accurately: making
modifying packages an officially supported strategy -- is not a good
idea. This simply wouldn't work well with updating packages from
repositories.
The alternative of having a union FS with a writable layer on top of the
read-only package contents sounds like a nice idea, but it has issues as
well. It adds considerable complexity to the implementation and it makes
things harder to understand (e.g. what happens with a modification, if
the corresponding package is updated?).
I think the current approach is pretty reasonable. We can support
overrides at the application level, where we think they make sense. E.g.
if did want to allow overriding Deskbar in an easy manner, the
Bootscript wouldn't hard-code its path, but rather search the possible
installation locations (or there'd even be a setting somewhere).
CU, Ingo
Other related posts:
