Still waiting for bugreports about specific BeOS apps not working. Still have not found any problems related to package management (there are problems for many other reasons, however).
I can’t help if you’ve turned a blind eye at this for years by now.
I dont think you can achaive anything with this passive-agressive way. You were told many times to list specific programs, but we havent heard anything.
Nobody ever said Haiku is final, nobody would say that about any OS, except maybe about IRIX. Haiku and its file-system is just what the Haiku devs made so far, not complete, not final and it will change/evolve. This is just what we currently have.
The ideas werent ignored, just nobody felt the urge to change it. You feel the urge: so can you show how it should be made? Pointing at GE is not enough, we got plenty ideas here.
Would you make a detailed description how the FS should looks like, how it should function, how should be implemented and what are the cons and pros, how many manhours will be required, what kind of knowledge/experiences will be required from the dev side, etc?
It seems you are lurking here hunting for user feedback to press your ideas, trying to divide the small user base. But this is wrong in so many levels: just lets look at this example: we got a feedback that the BeIA devkit doesnt works.
You came and said the fs is just horribly broken, while we dont even have a clear information whats wrong. did you made an analysis to see why it doesnt working or just lets your brain make assumptions?
I am in Budapest right now and the sky is full with stormclouds. Over Stuttgart too in Germany. Do i have the right to complain at the german embassy now? According you i have, or did i misunderstood something?
5 Likes
Nonsense. Utter nonsense.
Frankly at this point I want packagefs ripped out, and replaced with a sane simple and low maintainence package mangement system. Or that the very least a usable system to unpack packagefs packages that takes care of the various issues with that.
Moho 2.5 is not working anymore due to package management, since the paths are not correct anymore. It is working but you cannot save an animation.
1 Like
3 posts were merged into an existing topic: Imagining BeIA-like concept in 2020
Then rip it off, the license allows it and it was already prooved it is doable. No need for big emotions just git and some hours of work i think. If you met any roadblock do not forget to update us, it can be a useful information in the future for Haiku too, maybe some community members will lend a helping hand too. I wish you good luck.
3 Likes
Can we please stop these unproductive derails? We all know know how cb88 feels about packagefs and he should also know that Haiku won’t remove it. Can we move on?
8 Likes
I’m looking at Moho right now, and the problem is not in anything related to package, but to compatibility problems with the Media Kit.
I’ll update https://dev.haiku-os.org/ticket/11974 with my findings.
5 Likes
Thanks alot, your help is very appericated! I still have a valid Moho licence and I like this program much! It is easy to use and full BeOs program.
So I’m doing all the work myself here 
Here is a ticket about an app that has problems because of packagefs (trying to write in read-only directories): https://dev.haiku-os.org/ticket/9638 and the ticket has a download for a patched version of the app.
In my experience, anything that needs to unpack in the root file system and expects the layout BeOS had causes an issue. So - the BeIA Software valet package sort of worked - it seems to hate the Haiku Netserver and claims there is no network connection, but that is not the main issue. The main SDK I have was a zip file that needs to be unpacked on the root file system… and expects there to be a /boot/beos, /boot/home, /boot/develop and then expects all of everything in that schema to be writable. Looking at the R1 build I have on my Haiku netbook, I have /boot/home, /boot/system and /boot/trash. So if my zip wants to unpack in /boot/beos/system - that is complete nonsense in the file system. So /boot/beos/system/add-ons appears to be /boot/system/add-ons in Haiku. And develop is mounted at the system level, not the root. And /boot/System is a readonly file system, so even if I did try to unpack on the system rather than the root (assuming enough mapped) I can’t. This seems like a really big restriction and I don’t think it affects most people, but from a BeOS compatibility angle, it suuuucks.
You can unpack ZIP archive to root directory so beos directory will be created and then create symlinks from beos to /boot/system/non-packaged directory.
3 Likes
Or the opposite way:
ln -s /boot/system/non-packaged /boot/beos
mkdir /boot/develop # Probably need to add subdirecotries of this to PATH and BEINCLUDES
For /boot/home/config there isn’t much to be done however. You could attempt unmounting the packagefs from there since it’s not really used by the OS:
unmount /boot/home/config
Then extract your zip file and see if that gets you further.
Neither of these really help because some of what is installed in expecting to be able to be written to where the drivers and underlying configuration files are stored. Putting them in /boot/beos won’t really help unless the underlying mapping is writable. The physical layout of the file system is different and some of the directories are no longer writable. Is there a way to install drivers without them being packaged?
I’ll have a go with the non packagefs version of Haiku first. (edit and as someone asked after the release today and I found the link to the main page, I am now downloading the VM image as well as a backup.)
I expect I could probably work around all of these issues, but I guess it depends if anyone really cares?! This is very niche.
Putting them in the non-packaged directory (which is what will happen with the symlink I suggested) should work.
Indeed, but if you care, the experiment is interesting 
We will probably not go back on packagefs, but we can make the non-packaged directory work better.
Well, R1A4.1 installed, but it doesn’t seem to want to boot properly. If I boot from USB I can set “failsafe video mode”, but the once installed, no matter how often I hammer on space, it does not go to the boot menu. To be honest, this mightbe hardware as it also doesn’t seem to work on the other Haiku installs on this Netbook. I put a vesa and kernel config file in the /boot/home/config/settings/kernel/drivers directory, and set the failsafe and correct resolution but that didn’t seem to work. I don’t have time to take more of a look now, but will try again later.
You can force VESA in ~/config/settings/kernel/drivers/kernel by uncommenting “fail_safe_video_mode true”
I don’t know if this would help in anyone’s current struggles, but I have more or less successfully installed things by the following fraudulent procedure:
- make a package with no contents, just symbolic links to some arbitrary writable disk directory.
- install symlink package
- point software to system/ and run install procedure
- remove symlink package
- create package from the writable disk directory, and install that.
I have to admit that this didn’t go perfectly smoothly - there was some apparently unrecoverable packagefs problem along the way - but I don’t recall the details and anyway things still work. The main difficulty I encountered was overly thorough install procedures that delete things before creating them just to be sure - that will fail because not writable - but it’s a problem only the few files at the roots of the product install trees.
I believe that along with the symlinks I installed bogus versions of a few bin/ commands for this - possibly rm, ln, and install.
I don’t remember if I tried chroot - similar principle.
1 Like
Whilst that did work, it got a kernel panic. It looks like the input_server is unhappy. That’s weird as it booted from USB with no issues. I might have tries changing stuff in the BIOS, so I’ll go back and have a look at that. The R1 Beta boots just fine.
Nope, more BIOS tweaking and it just page faults now.