Hi, Am 20.02.2015 um 11:16 schrieb Ingo Weinhold:
On 20.02.2015 10:33, Stephan Aßmus wrote: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.
It's not "objectively" weird, is it? Others have pointed out some small benefits. I think both ways have benefits and draw-backs.
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.
Probably.
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.
Indeed I consider blending the contents of "non-packaged" in with the packaged contents where they are right now the optimal solution. I was under the impression, this was unlikely to be worked on by anyone. I realize that the path to this much more elegant solution would be blocked by the proposed changes.
Best regards, -Stephan