why not /boot/haiku ?

[kaoutsis]

why not the main folder /boot/beos should named /boot/haiku ?

[diver]

I would say why not /boot/system, but this would probably be post R1 change as this will break compatiblity.

[netster403]

y not /boot/haiku (or system ;) ) with a alias from /boot/beos to /boot/haiku? this would keep compatibility, and progressively move away from beos

[axeld]

There is already a /boot/beos/system/ folder - so "system" would be at least strange. I'm not sure if we'd really break compatibility, though. What application needs to access anything in /boot/beos/? If we've cleared that issue, there is nothing preventing us from renaming this to "haiku" for R1.

[jackburton]

The Beos hrev5 development tools needs to be unzipped in /boot, and contains references to "beos/..". So I guess we, at least, should keep a symlink to it, if we rename /boot/beos to /boot/haiku.

[wkornewald]

Why not /boot/os instead of /boot/haiku?

[diver]

Replying to axeld:

There is already a /boot/beos/system/ folder - so "system" would be at least strange.

No, i mean this file system layout: /boot/... /boot/apps/ /boot/preferences/ /boot/system /boot/system/libs /boot/system/add-ons /boot/system/servers

How about that?

[kaoutsis]

Replying to axeld:

There is already a /boot/beos/system/ folder - so "system" would be at least strange. I'm not sure if we'd really break compatibility, though. What application needs to access anything in /boot/beos/? If we've cleared that issue, there is nothing preventing us from renaming this to "haiku" for R1.

i made a small test: while haiku was running, i renamed /boot/beos to /boot/haiku and also i renamed every 'beos' string to 'haiku' string in /boot/beos/system/boot/SetupEnvironment reboot, and ... the system couldn't boot :-)

Then i had a look at src/system/boot: grep -r -n -e 'beos' ./* gives (i have removed the unrelated lines):

...
./loader/loader.cpp:27:#define KERNEL_PATH		"beos/system/" KERNEL_IMAGE
./loader/loader.cpp:31:	"beos/system/add-ons/kernel",
...
./platform/bios_ia32/stage1.S:8:; The partition must be a BFS formatted. The file "beos/system/zbeos"
...
Binary file ./platform/bios_ia32/stage1.bin matches

[axeld]

That's not really how you would go about this - at the very least you'd have to patch find_directory() to return the new directory.

Also, it's perfectly okay if we change our own code to comply with the new directory (like the boot loader, there is no find_directory() for it). It's just the question why any 3rd party tool would see the need to access the system directory.

[kaoutsis]

I don't see the src/system/boot/platform/bios_ia32/stage1.bin in the attached diff from trac; i am not sure if it is there (i certainly have regenerate it from stage1.S and i put it in the diff). It's a binary file and i am not sure how svn has it manipulated. May be you have to regenerate from src/system/boot/platform/bios_ia32/stage1.S?

Which 3rd party tools/apps should we test now?

[kaoutsis]

these two optional packages are using /boot/beos by default: 1) jam: /boot/beos/etc/licenses/Jam 2) links: for /boot/beos/etc/links.cfg

[tqh]

I can look thru Mozilla code for refs. Should not be that hard to fix if necessary.

[kaoutsis]

Replying to tqh:

I can look thru Mozilla code for refs. Should not be that hard to fix if necessary.

Ok, currently i have made an installation in /boot/haiku (see boot-haiku1.diff for reference, note that the patch is outdated). Firefox is running extremely good (i don't believe that there is any additional problems).

[tqh]

There are two refs in Mozilla, none which are really important. One is a fallback if there is no LIB env, and one is in a more or less deprecetad test-app.

[kaoutsis]

Replying to tqh:

There are two refs in Mozilla, none which are really important. One is a fallback if there is no LIB env, and one is in a more or less deprecetad test-app.

Good. So, can we assume that firefox is ready for the "/boot/haiku" transition, what's your opinion?

[diver]

This bug could be closed I guess?

[axeld]

There are a few problems left (remaining optional packages with licenses in /boot/beos/etc/licenses), but yes, I guess this one can be closed.

[PieterPanman]

Haiku revision: 29884 (close to 30000 already!)

Hope you don't mind me reopening this one, but I found a minor omission. I can no longer link against -lbe from inside haiku:

gcc -lbe -o DeviceManager dm_wrapper.o DeviceManager.o
/boot/develop/tools/gnupro/i586-pc-haiku/bin/ld: cannot find -lbe

I had to execute this to make it work again:

export BELIBRARIES=$BELIBRARIES:/boot/system/lib

before it was BELIBRARIES="/boot/common/lib:/boot/develop/lib/x86"

[anevilyak]

Fixed in hrev29886. The build for symlinks in lib/x86 was broken.