On 09/29/2013 11:08 PM, Axel Dörfler wrote:
On 09/29/2013 12:31 PM, Ingo Weinhold wrote:Given that the discussion has died down and I haven't seen any technical argument against it, I would like to go ahead and start the change.I guess there just aren't any technical arguments against it. I would prefer to have a system separate from common to have everything that is the core of haiku in a single directory. But since that is all, I don't mind too much if that doesn't convince you :-) Well, I have one technical argument, after all: how would you override system level things (like an add-on) for all users?
Good question. If your replacement is not packaged then you could just install it in /boot/system/non-packaged. If it is packaged then things get more complicated.
If you drop your package in system then its files can override the files from haiku.hpkg. IIRC the currently implemented algorithm simply decides based on file date. The newer file wins. Obviously this algorithm could be made more intelligent. Since your package is build intentionally to override system files, we could introduce a marker in the package meta data to indicate that purpose. packagefs would then always prefer files from such a package.
Alternatively a respective flag could be specified when installing a package. The information would then not be stored inside the package but in the administrative data used by packagefs (in the "administrative" subdirectory).
Yet another option to specify the information would be to provide a second "packages" directory (e.g. "packages-overrides" or "packages/overrides") whose packages would have a higher priority than those in the standard "packages" directory, with just the same effect as the external flag.
A related problem is that of disabling system components (e.g. problematic drivers). That's something a separate common hierarchy can't help with either. So maybe a solution that can deal with both could be sought. E.g. a settings file to hide specific files of packages. I'm a bit worried that this will become somewhat untransparent for the user, though. Given that this will probably be a very rare feature to be used, that concern might be unfounded. And the system (the package manager) could also help to keep the potential issues in sight (e.g. asking/warning explicitly when a concerned package is updated).
CU, Ingo
