The new package management system, and reason for its existance.
In my opinion it does more harm than good:
BeOS has achieved a good balance between automated and manual installation, the user felt, that he controls his system.
I understand the need for greater system security and etc, but this is what is done now, I think it is too difficult and complicated.
I think this new package management system should be left exclusively to the systemic issues and not to obstruct the Home folder, leaving the user to deal with what to do and how. As well as third-party programs should go to the /boot/apps, that SoftwareValet type program can handeling.
I also think that this system is contrary to the distribution:
– system
– application
– user
That being said, what you are stating seems to be the consensus opinion of everybody that used BeOS and is not on the Haiku Development team. The Haiku developers disagree, mainly because they are afraid to admit that they made a mistake when they messed up the home folder.
As someone who has run and compiled a large number of applications for Haiku I can tell you that the old way was not working. Any time I went to Haikuware.com I could retrieve an application that needed BeOS V2, V3, V4, V4.5, V5.2, or Haiku A1, A2, A3, A4, or required some exact version of just one lib. Many applications used many libraries. In fact, the better the application, the more libs it was dependent on.
Many libraries are not distributed with the core Haiku. For size, and for maintenance reasons. As times I was resorting to downloading the big library bundle and installing that. But this created big problems. An older app would break with a newer lib, a newer app would break with an older lib.
If all you do is download Haiku and play with the installed demos, you never see these problems. But if you are trying to port many applications, with many libs, it becomes a nightmare.
The same problem was experienced on early versions of Windows, and also on Linux. Windows created an internal database called the registry. Linux created package managers. On Windows we called the problem DLL hell. It could lead to your system becoming unstable with random crashes.
On Haiku we under estimated the effort to create and maintain the package management system. This is true. It is at times painful and slowed down the Beta release. But is has huge value for keeping your Haiku installation stable, keeping the apps stable, upgrading future versions of Haiku, and even for coordinating Haiku X64 code.
When I finally understood the values of the package manager, I decided it was ultimately a good thing.
The package management system was radical cut but a good one. I for my self was not afaird about the PMS (Package Management System), because i have the same concerns like you, but working on my Haiku Package Creator let me see more behind the system and that it is:
No porgram are installed in the file-hirarchy, they are linked out of the hpkg file.
Faster installation and deinstallation.
Old pkg files from beos are installed automatically under non-packaged and they are running.
The folders for packages and non-packages from the user site (home) have take precedence
Ok they are some thinks that can be otimiced, but all in it is a good way. Yes this PMS braks many packages created in the past, but with the support for pkg files the compiblity of beos apps are available. The bigger disaster was closing Haikuware without storing all the files into a wayback machnine.
I know about problems with libs, that problem was on BeOS to.
And yes, there is Windows and Linux way to deal with it. Metods of dealing outgoing out of systems architecture and capabilites.
I think BeOS-Haiku way deal with it – use file atributes and internal OS message system. Program must know what version of library it needs, and it must ask system about it, at system must have to know what versions it have at provided what is needed, even if that version is in another programs lib folder, maybe asks users permisions for that. What is needed for realisation of that? some database?
Actually I have some ideas about that problem and beyond… some time I think about it.
Haiku must have paralel virtual file system based on categories of data types, defined by file atributes. Its like oposite to traditional file system where files are structured by place. Virtual fs must be structured by data type. OS can use that virtual fs to organise and make decision what is for and what is not (and even more: os can have methods of doing things, and programs can use that). Even user can be capable to browse that virtual fs in some way.
Having a (good) package manager is not bad. Consider, however, that we didn’t have this type of package manager in BeOS. I am not saying everything was fine, but we did have a lot of useful applications, and now that there is a huge effort trying to recreate BeOS, we shouldn’t spend resources (including donated money) on a feature that BeOS didn’t originally have. Finish Haiku OS beta first. In fact, get Haiku OS final out, and then later add whatever new feature you’d like.
Package management was switched on with hrev46113 on 29 September 2013. That’s right, more than two YEARS ago. There is nothing “new” about it any more. If people feel so strongly about it, there is nothing to stop them from grabbing the source for the last non-package hrev and setting up their own project to show us how it should be done. Complaining and suggesting alternatives on this forum will lead to exactly nothing. Take the code and show us. The Haiku devs are not going to drop four years of work on your say-so.
In the last year I have created over 340 packages for my repository, so while I am not a dev, I think I can claim some experience with the system. It works. It is a beautiful, innovative system that does what it claims to do. It creates virtual files and directories according to the packages installed. Uninstall a package and there is nothing left littering your system. When you actually start working with it, it is awe-inspiring.
Perhaps people don’t realise just how deeply package management is integrated into Haiku now. Haiku itself is packaged. there is nothing left unpackaged but a bootloader stub and just enough to start installing packages. It’s not as if there is a large unpackaged base system, while user applications are packaged. This is much more radical than anything on Linux, Windows or Mac OSX. There is immense future-proofing built right into the system and when Haiku goes beta, it will be a major selling point.
Are there still rough edges? Sure, that’s why there are new nightlies coming out. Are there things that could have been done differently? Yes, but those decisions are in the past and can’t be undone without tearing up four years of work.
Give it an honest try. Create your own packages. It’s not difficult: if you have ever zipped up some files from the command line you can make your own HPKG, and then you have the user control you seek (no, you don’t have to go through HaikuPorter, you can use the ‘package’ command on your own system). Explore the 3rd-party repos (there are 5 of us now). The PM system is not going away and no amount of BeOS nostalgia will make it.
Or show us how it should have been done. I’ll keep a partition empty and waiting for your product.
Sorry if I offend you,… but I need more clarification, to me this package system is new, I do not know how it works.
For example, why is there directory “non-packaged”? – I think it not needed, “packages” well incorporates in old directory layer.
For me, “non-packaged” is not beautiful.
How system prioritise between “non-packaged” and “packaged” the same or the same looking applications and libs? How with conflicts? how with conflicts in “home” and “system” installs? We still need “home” installs?
“Be” menu is corrupted: I can’t make links, can’t edit it. Why it can not be old “be” menu (directories with links) with incorporated ‘packages’ links?
There’s a bit in the user guide, limited to what’s most interesting to the enduser. Not everything is yet available, as the guide would have to be exported from the userguide site first. Hopefully soon…