[haiku-development] Re: I suggest a vote on 3 items

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 3 Sep 2015 13:18:07 +0200

Hi Adrien,

Am 03.09.2015 um 12:48 schrieb Adrien Destugues:

... sorry for replying to myself. Just wanted to add, and this has been
mentioned before, that a
lot of people including myself thought that both the packages and non-packaged
folders would
contribute to a /single/ directory layout.

I regret that it wasn't done, but
I understand the reasons. However, that difference would have been more
intuitive

I'm not sure about that. The fact that the writes would be somehow
"overlaid" over the packages can lead to confusing situations. What
if you try to backup your install? Should you copy only the packages?
Should you copy the mounted contents, and if you do so, how do you
restore the install from the backups?

The backup example doesn't convince me. What happens if you do a backup now? If you just copy everything you can see (read), you would backup the read-only packaged stuff as well, even though you should only back the packages themselves.

And if you use some smarter backup method, you would skip the read-only packaged folder structure, but you would always backup the contents of non-packaged.

Now, if non-packaged would be merged into the package fs, the /exact same/ method of backing up (and restoring) your files would still be correct, nothing would be more complicated in this regard.

I don't think that would be intuitive at all. Everyone can understand
what a read-only directory is. Understanding an overlay system with
two layers is not as easy, and doesn't qualify as "intuitive". We
have an example of overlaying writable and non-writable directories,
in the form of the DeskBar menu. It is definitely one of the most
confusing parts of the whole system (2 directories of which one is
packaged, a file to bind them together that Tracker and DeskBar
pretend is a directory, but which you can't access as one in
Terminal, uncertain priorities (what if you want to replace a file)
and strange limitations (no way to delete a file from the packaged
dir)). And using it in a global way would raise some other questions,
such as what happens when a package update
replaces/creates/deletes/moves a file that you modified.

All I can say is that I was not the only one who thought it worked that way, but I haven't dug up the links to the discussion within the relevant blog posts. So there is an argument there that for some people it would have been more intuitive. (The logic being, me plus someone else, there must be more...)

There is already a way to black out files from packages. This was needed to disable certain drivers from the haiku package which caused problems. So the non-packaged folder wouldn't need to serve that purpose. But it could be used to add files and to "overwrite" files. Both of which can be quite useful, and there is the side-effect of not introducing more find_directory() constants and more PATH components.

/and/ would have
avoided a lot of compatibility issues some of which are still present.

Do you have a list of compatibility issues? I think we have solved
most of them already. I can think of only one problem, which is that
the user non-packaged directories are not seen by apps using the
FindDirectory API (the packaged dirs are seen, and
system/non-packaged is mapped to the old "common" directory, IIRC).
We have introduced BPathFinder to make the API more flexible and
avoid this in the future.

Are there other problems left?

I don't know any others off the top of my head, I was referring to the same problem. That still qualifies as "some issues are still present". :-)

Best regards,
-Stephan

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 09-2015