[haiku-development] Re: Removing /boot/common

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 04 Oct 2013 23:41:36 +0200

On 10/04/2013 10:19 PM, scottmc wrote:
On Fri, Oct 4, 2013 at 12:00 PM, Oliver Tappe <zooey@xxxxxxxxxxxxxxx
<mailto:zooey@xxxxxxxxxxxxxxx>> wrote:
    On 2013-10-04 at 19:34:43 [+0200], John Scipione
    <jscipione@xxxxxxxxx <mailto:jscipione@xxxxxxxxx>>
    wrote:
     > I'm a bit late to this discussion, but, won't this break binaries
    that
     > specify /boot/common instead of using the B_COMMON_DIRECTORY and
     > friends paths or how does that work?

    Yes, software that uses a fixed path pointing to /boot/common will no
    longer work. Then again, that software is conceptually broken anyway, as
    the precise reason for having find_directory() is to avoid problems when
    directories move around.

Keep in mind that /boot/common was added to Haiku it wasn't in BeOS, so
there's a very good change that any software that gets broken by this is
still fresh enough that it can just be fixed/recompiled.  IIRC there's
been no promise to be binary compatible with previous versions of Haiku
pre-R1.

... though we generally try not to break anything, if not necessary. In this case, there's no silver bullet. Hard-coded /boot/common paths are broken by design and there's nothing that can be done.

The B_COMMON_*DIRECTORY constants for the writable directories have been redirected to the respective directories in /boot/system. So, code using those will be fine.

For the constants referring to non-writable directories there's a dilemma. Redirecting them to the respective /boot/system paths will cause code that iterates over certain directories in all installation locations (e.g. all "fonts" directories) to encounter the same directory twice. This may be a problem, depending on what the code expects and how it handles duplicates.

Instead I chose to make the constants resolve to an empty or non-existent directory. This avoids the duplication issue, but code that expects something specifically in some B_COMMON_*DIRECTORY directory will no longer find it. Due to the multiple possible installation locations for packages, this is something that wouldn't work reliably anyway, though.

I removed the B_COMMON_*DIRECTORY constants from the public API, so any code using them will now fail to compile and thus force a review of the code. This is a good thing, since support for the non-packaged directories needs to be added as well.

CU, Ingo


Other related posts: