FYI: I saw that somebody posted a well-written article on the Haiku package management system here which may be of interest.
1 Like
I think it’s already mentioned here:
But it is indeed an interesting article. 
Thanks for this link. For me it is a very interesting article. I am learning day by day a little bit more about Haiku. Till now I can use apps and do daily tasks with Haiku but I have to learn much more about the things inside the system.
That’s a great article, stylistically refreshing. So glad to see he is a BeOS user and understands the forward thinking path that Haiku is taking. Thanks @apl !!!
I enjoyed it to, and rather hope the author is able to find time for more “deep dives” into Haiku’s inner workings. I did not understand the technical reasons but got the takeaway that we have a better package manager than almost anyone else including the GNU scene which has seemingly been struggling to get it right forever.
Kudos also to OSnews for directing its readers to this article (and author).
Well, it can certainly be improved 
Just trashed my install by deleting a work directory of haikuporter and deleted all files in /system/packages … feels like one of the things that shouldnt be possible.
1 Like
I’ve done that many times and never had that happened to me… It’s pretty common for me to run find . -name 'work-*' -exec rm -rf {} \; in my HaikuPorts tree now and again.
(you can use the -delete action instead of going through -exec rm, it will avoid running a separate executable for deleting the files)
2 Likes
I think this has to do with either symlinks or how rm treats filesystem boundaries.
In any case, I think the current design leads itself to such (user induced) errors easily if you aren’t 100% sure of how it works adds each directory.
If you remove the work directory entirely, you are safe.
If you remove the system directory inside it, you are safe
If you remove work/system/packages and work/system is a symlink to /boot/system, you delete things in your /boot partition.
Nothing special or surprising here, really. But it’s indeed easy to forget that some things are links to the real system dir. Is it intentional. Was it meant to be links to the system directory inside the chroot but then it doesn’t point there anymore when exiting the chroot? If that’s the case, can we fix it by making these relative symlinks instead of absolute ones?
Not sure what you mean by that, removing stuff inside work/system/packages does indeed delete then from the system dir. I think as a user this is unexpected, even if it is intentional as you say. I don’t think i should be able to delete my OS because i did something in the haikuports tree.
Maybe I am just salty because I managed to do that anyway
I’m just saying there is nothing “magic” or “broken” about it, it’s UNIX filesystem working exactly as expected: symlinks point to /boot/system, so if you delete something in there, it deletes it in /boot/system. I agree however that it is dangerous, I have also partially broken my install because of it recently.
The next question is why these symlinks are there. When haikuporter runs, it uses a chroot. This means it creates a separate “/” directory and uses a copy of the main filesystem there. I think the various symlinks in the work directory are meant to point to the /boot/system directory inside the chroot. But if you access them from outside (going in the work directory from your shell, instead of, for example, using haikuporter -e to open a shell inside the chroot environment),the symlinks end up pointing at the real /boot, because a symlink is a bit stupid: it’s just a file with the absolute path of another file as a content.
So, if these symlinks were made relative, that is, instead of pointing to /boot/system/whatever, they would point to ../system/whatever or something like that, they would point to the correct place no matter if you’re looking at them from inside or outside the chroot. This would be better.
5 Likes