There is a post on OS News about the merging of Package Management branch into master. It it a portion of the PM merge post by bonefish last week. The post ends “Onwards to beta 1.” While I think more work needs to be done before beta 1, I agree beta 1 is the next logical step!
http://www.osnews.com/story/27355/Haiku_package_management_goes_live
Great news!
I have a couple questions about it …
[quote=ddavid123]All of the documentation about package management can be found below. Keep in mind that it is still a work in progress, so all of the features may not be documented.
http://dev.haiku-os.org/wiki/PackageManagement[/quote]
Thanks!
All of the documentation about package management can be found below. Keep in mind that it is still a work in progress, so all of the features may not be documented.
If you haven’t tried a recent nightly, then you don’t know:
Will Haiku fall flat on its face ? http://fatelk.com/faceplant.htm
For the usability, well, it runs as well as before. You have to get used to having a read-only system and, maybe that’s more of an heated discussion, /boot/home/config. Some apps will hav trouble installing and/or finding their own files: we are listening to bug reports for BeOS apps that fail to run and will find ways to get them working again. As for apps that were written for Haiku and now don’t work, the fixes have to be done on the application side.
why is it read only?
[quote=bbjimmy]If you haven’t tried a recent nightly, then you don’t know:
Will Haiku fall flat on its face ? http://fatelk.com/faceplant.htm[/quote]
As i’ve replied to Karl on Haikuware:
Do you remember the old optional package named “BeOSCompatibility - creates links within the system to support old apps”? Well, in these weeks i have found that some apps on Haikuware, doesn’t work at the first attempt on Haiku PM, since some of these expect to look in the old path “/boot/apps” (or “/boot/common”).
Well, on my system i run some of these old apps by making a symlink from /boot/config/apps which points as /boot/apps, and these apps works again on the “new” Haiku.
Ok, this is a workaround, but was the same using the old optional package "BeOSCompatibility ".
In anyway, for what is worth, i am doing hpkg packages from these old apps.
previously, adding apps was a drag & drop operation – why is package management now so complex when a script could easily place a file where it needs to be? what problem is addressed by the added complexity? i’m all for a browsable interface of available apps, but this is a bit much – like, how am i to manually install apps from elsewhere if access is read only? i’ve yet to get this system online even once, so all i have are questions.
hearing reports of many apps having broken, and now work being undertaken to fix those apps and make them into packages, it’s a bit weird – that’s a lot of effort that could’ve gone elsewhere had the package management simply interfaced with the existing filesystem with its existing permissions. instead, all things must be ported, so that native apps may run again. how does that make sense?
We are still able to drag and drop apps, but inside the “non-packaged” folder 
Look here: i’m running all apps (also old apps) that i use since years on Haiku:
For those apps which explicitly looks in removed folders (eg /boot/apps and /boot/common), there is the workaround of symlinks.
And new (upcoming) apps could be compiled.
ah, cool. does a recompile of old apps work if i have the source, or will they need something more? still not feeling good about read-only stuff and felt the warning upon opening system files (with the option to open them read-only or read-write) was pretty cool and also kind.
Not every old apps need to be recompiled. Has been changed the folders hierarchy, and if an old app relies on /boot/apps (for example) you just need to create a symlink. I have done this on my system, for those apps which need this path, and these apps work properly as before.
Obviously having the source of apps is better in anyway and in any situations 
And about read-only folders there is the the counterpart which are the read-write folders (eg non packaged, or /settings both on config and system)
Normally, it’s still just a drag&drop (or, once repos are operational, all searching/downloading/installing/uninstalling is done from HaikuDepot). Please have a look at the article Installing apps in PM Haiku.
If apps rely on hardcoded paths they’ve been broken all along and only worked by accident. But even then, as PulkoMandy said, solutions are being found to accomodate most of those.
Regards,
Humdinger
My comments were intended to get the Haiku applications devs and Haiku users talking about these changes. Discussing weather these changes bring any real value to Haiku or not. Package management is not the issue, the issue is how it is implemented. The haiku devs seem to feel blindsided by this discussion as package management builds have been available for testing.
The point is that even after it was merged, most people do not mess with nightly images and just use the latest release. I wanted people to notice what they were planning for Haiku and discuss it before the next release. I don’t want to read reviews of Haiku beta 1 concluding with:
“Don’t bother with this operating system, even with the limited software available for it, most of that doesn’t run.”
Except, the real problem is that the “limited software available for it” is largely crappy ports, abandoned apps where the devs lost interest, and poorly written stuff by amateurs.
You can’t make that problem disappear - and you can’t thrive with such a situation either.
What we need is well built, well packaged software, with dedicated developers who will maintain it and repackage it properly.
I cannot believe people still believe the “unzip to /boot” is a packaging solution - it was more-or-less discouraged from day one as a temporary hack, and yet nobody seriously came up with anything better until 10 years later. And now 10 years later, we’re dealing with 10 years of shitty software packaged with a hack, and people complaining. What did they think would happen? Why do you think Haiku hasn’t become “beta” yet? Alpha software means it’s not done, and stuff will still change - and when the final big piece is dropped into place, and stuff changed (as was promised it would), everyone decides the sky is falling, and they’re too lazy or incompetent to improve any of the “broken” software.
umccullough wrote:
Alpha software means it’s not done, and stuff will still change - and when the final big piece is dropped into place, and stuff changed (as was promised it would), everyone decides the sky is falling, and they’re too lazy or incompetent to improve any of the “broken” software.
This will be the case if the applications developers do not know what the changes are going to be. That is exactly why this discussion is so important. Lets be fair, most devs are not lazy or incompetent and do not wish to be associated with broken software. To prevent that they need to look at the changes and prepare for the future.
That being said, I do not believe making ~/config read only brings any real added value to Haiku. As well, it makes the operating system more difficult to manage for the user. It starts to make Haiku seem like a locked down version of android or some other mobile operating system and less like a desktop system.
I understand what the goal is, but I think the implementation misses the mark. I think it is time for the Haiku devs to get down off of their high horse and walk and talk with the commoners. Maybe they need to actually use Haiku instead of their favorite version of Linux. As I have said before, the directory lay-out and how it works IS Haiku, It is what sets Haiku apart from the more complicated stuf in Windows and Linux distrobutions. Changing this changes the user interface as surely as a change to the Deskbar or Tracker do. With these changes, the real value that Haiku brings to a desktop computer is deminished.
I’m not going to comment specifically on whether ~/config should be editable or not - I think it’s focusing on too specific an issue at this point, when I believe the real problem is that we have a trove of stale software that needs to be repackaged and/or fixed to meet future design goals of Haiku. What happens if we go down this path, and a year from now it turns out you were right and we change everything back? Software that is built to use a packaging solution we’ve defined, will continue to “just work”, while any further hacked software that unzips to hardcoded paths will simply fail again. That is what has happened with /boot/common.
Sorry, this idea that the haiku devs are somehow “above” the commoners rubs me the wrong way.
Haiku is a volunteer-based project. The reality is, there is a small number of people who are 1) knowledgeable enough and 2) motivated to even be working on Haiku in the first place.
Maybe more of the “commoners” should rise up to participate and help out with the project.
There has been a very small number of people who have time to work on and finish areas of Haiku, and even fewer who have approached Haiku, Inc. to seek payment to do so. The latter seems to be a point of contention among certain community members, and creates undue animosity toward the developers and Haiku, Inc. decision makers.
I agree that the discussion should occur between those who develop, and those who use - but I think the discussions are happening in the wrong places at this point. The only real common ground is the mailing lists.
I see a lot of fringe “discussion” happening that is mostly being ignored because it’s not the central communication channel. These forums for example, the IRC channel, Haikuware, etc. Furthermore, I see a lot of misinformation being disseminated in these fringe areas by people who neglected to properly understand what is going on and why something is ‘broken’… and that chaps me.
At what point will these “commoners” respond back with the logical solution: A fork of Haiku that does things the way they believe is right? I’m not saying that’s a healthy solution to this problem, but in the world of FOSS, it’s the logical conclusion when there are multiple factions of people with extremely disparate views on how the software should work. Sometimes the new fork wins over a substantial amount of the user base, and many of the developers jump ship as well. Recent examples I’ve seen being X.Org, LibreOffice, Linux Mint, MariaDB, etc.
So far, I’m seeing far more complaining than attempts to resolve the problems at this point - which doesn’t impress me all that much.
I too have ported a few things to Haiku over the years - I’m gonna eventually have to go back and verify that none of those are broken - I realize they’ll need to be repackaged. Fortunately next to nobody uses the stuff I’ve ported, so I don’t have people complaining to me that I need to fix it 
umccullough wrote:
The only real common ground is the mailing lists.
I see a lot of fringe “discussion” happening that is mostly being ignored because it’s not the central communication channel. These forums for example, the IRC channel, Haikuware, etc. Furthermore, I see a lot of misinformation being disseminated in these fringe areas by people who neglected to properly understand what is going on and why something is ‘broken’… and that chaps me.
That is not true. The mailing lists are the territory of the devs, and if one attempts to start a real conversation as a user, the devs feel threatened, and slap down the commenter. Here in the forums, they feel compelled to at least be civil. I know, I speak from experience. I do not like to be told that I know nothing and to shut-up! They need to come here and listen, and respond in a civil manner.
Haiku devs are not unlike most programmers I have dealt with. They can do great things, but have difficulty communicating with people who use those great things. They need to understand, that no matter how stupid the statement or request, there is a great deal of truth in it, at least to the commenter, or he would not have broached the subject.
I have not yet heard a valid reason, other than “that is how we did it”, for making ~/config read only. I have not heard a dev respond to the fact that they are changing the user environment and making it harder to use and navigate. This stuff matterrs, but they will not listen to our arguments, they cannot get past the idea that a user is invading their space. They think they are being challenged, they say “SHUP_UP!”
Tell me again why I should not think they need to get down off of the high horse and come here and talk to us?
Personally, I both love and hate the package management system.
But it works, and for what it does it works well.
While no 4 star software I plan to rewrite all my programs to fit better with the present Haiku-OS and it’s package management system.
Does anyone know how I remove my present software from BeBits and Haikuware? I don’t want to just package the present code, all them need up-dating before I release new packaged versions.
i’m pretty well reassured. thanks humdinger and pulkomandy for coming in and speaking up.