On 20.02.2015 10:33, Stephan Aßmus wrote:
Am 20.02.2015 um 09:29 schrieb Axel Dörfler:Am 19/02/2015 um 21:29 schrieb Adrien Destugues:And what I'd prefer in that case (I'm fine with either this or the current one): /boot/system (not packages) /boot/system/packaged (packages) ~/config/packaged (packages) ~/config/ (not packages)Same here. It's consistent, and does not add more cruft to the user folder.I don't know how the modifyable parts of packages fit into this (settings, additional users, post-install scripts)... or rather I should say, I don't know how much work is required to change this cleanly, but I could live with this as well.
I haven't fully thought it through, but I moving the writable directories would probably be a bit of work, i.e. more than changing constants in two or three places in the tree. Besides some work in the tree, it will at least be necessary to adjust haikuporter and likely a few recipes, and rebuild all packages.
There is the argument that this somehow degrades package management to second class citizen. But I don't know how strong that argument is. For the hypothetical users that don't need to know about these internals, it should not matter by definition. The others are the power-users and developers. And if it makes (at least some of) their lives easier, I don't see much against it.
The argument isn't so much that users may be confused -- as you write, depending on their level they won't be or they won't even know -- it's that this is a weird way of organizing things: Virtually all software lives in a subdirectory while the prominent places (/system/* and ~/config/*) are essentially empty.
FWIW, since one of the arguments is to repair old stuff that hard-codes paths, I suspect some (not quite as old) software that does the same will break when suddenly the subdirectories in /system no longer contain the system executables and libraries.
And finally, since you have been a proponent of a (simplified) union FS solution in the past, please note that moving the mount point of our virtual file systems away from where the union FS would have to be mounted and instead using those locations for actual file storage would be a step in the wrong direction for that purpose. So should we consider a union FS solution the way to go eventually (even post beta 1 or R1), moving mount points would be detrimental.
CU, Ingo
