Yep, SONAME changes are how ports handle ABI breakage.
Haiku itself only hard-breaks ABI between versions; at this point, we probably won’t break ABI again between now and R1 (though we may add new API calls or change syscalls, the former of which we have already done, and the latter we will probably do at some point to add more XSI stuff.)
How does your approach solve this problem, anyway?
I don’t know what you mean by “it’s not clear” what libraries come from what package. Just check the attributes:
~/Desktop> catattr SYS:PACKAGE /system/lib/libavfilter.so.7
/system/lib/libavfilter.so.7 : string : ffmpeg-4.0.3-1
~/Desktop> catattr SYS:PACKAGE /system/lib/libbe.so
/system/lib/libbe.so : string : haiku-r1~beta1_hrev52829-1
There are no complaints about Haiku, now the OS is in development status and everything can change. This is normal. The main thing is that in future versions BeOS Abi (gcc2) will not disappear.
I meant the problem of the very ideology of the package system.
A simple example. In 2016 or in 2017 I compiled qt4pas for Lazarus. In 2018 it stopped working because qt4webkit was missing. This feature has been removed. If I did not trust the package system and include all the necessary libraries in Lazarus, then everything would work.
And now it is clear to me why commercial programs always install with necessary libraries.
In BeOS (/ boot) there was a folder /beos /apps and /apps. Third-party software was placed in the /apps folder. In the /beos/apps folder there was only Be Inc software.
Now everything is in one folder /system/apps. This is similar to how in Windows all programs would be placed in thec:\windows\system32 folder 
The developer folder was separate and even gcc was in its separate tools / gnupro folder. And you could have several compilers there (for example, one version, but different build) and switch between them. I liked this difference. Now everything is in one folder.
Previously, it was possible to store different language compilers (gcc, pascal, python …) in the develop/tools folder.
And a little more about DeskBar Menu. Previously, I could make subfolders and place programs in groups. Now one huge list Application. Maybe there is some setting in the Haiku now to make subfolders in the menu?
I like BeOS way more too in this matter. Seems
Haiku taking over complicated features from Linux and Windows more easily than it should. There was a logic in BeOS way to handle things in the file system itself, too make many over complicated things not necessary.
What was needed is to continue in that direction, but urge to port software from Unix like systems made influence on Haiku to adopt their bad habits.
If BeOS way in this matter go to evolve it must be similar like it is made in GoboLinux. File system by itself must handling installed software.
Now what is done with installs in Haiku it is not a BeOS way.
Long standing issue (ticket #10557) that comes up in the forums regularly (last here). The user guide describes how to change to a manual managing of the Deskbar menus.
More intelligent managing is wanted, but the right way to go about it hasn’t been found yet. As always, patches welcome, but if it were easy to come up with a solution everyone is happy with, it’d be done by now, I suppose…
Painful only insofar as it rehashes all the old discussion of the past 5+ years and tempts the devs to spend their valuable time explaining, again how and why.
And it may even burn more ressources of Haiku if Hakilo users report Hakilo-specific bugs at the Haiku bugtracker or in this forum. It may not help much, but it’d be the least to inform the users when they apply the Hakilo-scripts that they cut out a major part of Haiku and that bugs should be reported at the Hakilo bugtracker. Maybe host your scripts at github and use their wiki/issue tracker.
Not true, package virtual file system is not major part of the Haiku. It is a small and only additional part. Haiku can work without it.
And it is obvious that main Haiku devs not interested in this. But this is not prevent to do something about it other people, it is open source project after all.
Remember that without package manager, we would never have gotten LibreOffice to run, or all these Qt apps in a sustainable way.
The package manager is completely orthogonal to many of the problems mentionned. You can put things in develop/tools from a package (actually Rust packaging may use this). We already have two different toolchains there (gcc2 and gcc5). It is still posible to put self-contained apps in /system/apps in a package if you want to.
So, nothing was lost in that regard.
On dependency hell: people have been quick to forget how easy it is to break an install before package management. Countless time I broke my install because some “unzip to /boot” package overwrote gcc2 libraries with gcc4 versions. Now this is not possible anymore.
Now that this is fixed, we get a lot of software ported in a sane way, and yes, this means a lot of dependencies and fragile ABIs, because the Linux software just works this way. The solution is of course to not install such software. Or use the package manager to at least not manage the dependency hell manually (don’t try to tell me dependency hell in the hands of the user is a good thing).
So yes, the package manager makes our lives so much easier because dependency heal is something you can work through now. It is still annoying, but not to the point of preventing progress in porting applications. And it is now available to users too, as a result. Yes, we should try to minimize dependencies and breakage, but this is a goal to research at haikuports, by improving the checks in haikuporter, and adding more policies for sane things. Changing or removing the package tool will not help. Dependency hell will still be there.
Is it a flaw in a system design if it needs additional package management and even additional file system for that management.
You can still unpack your beos apps to /apps. But you won’t get libreoffice this way. It’s a flaw in the linux ecosystem and we can’t fix it, but at least we can use the apps, and we also get a safety net when messing with the os.
Can be libreoffice installed in one folder with all dependencies?
Even if it could, the amount of time and effort it would take to make it build and run that way vs. using a proper package manager to port all the dependent libs first is so much less that it’s pretty much the only way it’s done. Windows is the exception here, and LibreOffice’s developers spend time on it pretty much only because of how many people use it.
Please stop saying this. We have made it an integral part of Haiku. Could you run an OS without it? Yes. But we have chosen to use it.
OK, I just will say, that I prefer BeOS like directory structure for Haiku. I think it is most perfect. And it needs only one addition: separate folders for separate versions (like in GoboLinux). And some installer-uninstaller (appart from deleting or putting some needed folder in place) will make links to last installed library (for example) in main lib directory, or if instructed by user it would make other link from other version, even for some app in app’s lib directory (that app even can ask system for that). Reversing to some older system state would be only reversing to some older links state (which can be saved).
And policy for installs must be:
/apps — for third part apps, or additional software (which is not necessary to run Haiku Operating System)
/develop — for develop tools, sources etc.
/system — for only Haiku System things (directory must be protected by password)
/home — for all additionally installed by user things
And there is no need for fancy system package virtual file systems.
Your contributions to haikuports to improve packaging and move things to the right place are warmly welcome.
If you are here only to complain and not get anything done, however…
I am not complaining. I just defined potentially standard directory structure for Haiku or for some Haiku derived distro, which is evolution of BeOS file system structure, actually. And this is something done, however.
I did what I can. May be it is not enough…
But I can complain if you want, there is much to complain about Haiku, but is a problem here that no one wants to listen.
Can the current version of packager make packages that are installed in a folder other than /system ?
If I make a package with bin, apps and other folders, they will be visible in the /system folder. I can’t make a package with the /boot/apps folder.
Correct me if I’m wrong.
The package Manager installs into /boot.
As you say, this is the problem not of the package manager itself, but of software packaging. And this problem exists in absolutely all and any package managers able to install a bit more than software with no or trivial dependencies.
Speaking about CJK fonts (and other stuff of large size and not used by many), some package managers (namely Debian’s .deb + apt) along dependency also has the notion of suggested packages. When somebody installs a package, it always installs its dependency and suggests to install some more packages on user’s discretion. Moreover, the user is able to uninstall these suggested (but not dependent) packages without being forced to uninstall the main package.
It is possible until the first software update. After it, Libre Office most probably won’t start. And exactly this kind of very rich dependency solves current Haiku’s package manager.
Personally I see HAKILO can collaborate with Haiku in exactly issues related to packaging: what is included in package itself, which packages should be declared as dependency and what should go to suggested packages.
