Okay. What usecases remain for which the Haiku package manager does not suffice?
Yes, actually, let’s. Not to debate the what of the package manager, but it has been a few years: let’s see what things there are that we cannot do that people wanted at the time, or thought we would never be able to do with our model, and see what of these remain and what we can fix.
We are Haiku; we have our own philosophy, so that is not a good argument here indeed.
We are here to find the best solutions possible. Personal attacks are obviously unacceptable; but actual criticisms of the design and implementation of the system are what we are all about here.
What old machines are these? By 2004-2005 most machines had at least 512MB of RAM; and packagefs can run just fine in this, especially after recent changes. We should optimize more to try and cut out that “last 100MB”, but I mean, if you want to run Haiku on a 486 you are going to be out of luck anyway.
Besides, it seems a large number of users’ “old hardware” is 2008-2012 era, which has more than a few GB to accommodate for Vista’s hogging, and the like. Packagefs eats far less than Vista did, so we are fine for now here.
No, I am actually not. What issues actually remain? I know that s40in opened a ticket about high packagefs memory usage, but if it is not actively getting in the way of running applications at present, what is this for?
To my knowledge, all the issues people were running into with packagefs, i.e. they had some usecase it did not handle right, we solved. There are a few more new ones (mostly about running apps off flash drives) that are being talked about now. Otherwise, I really do not know of outstanding usability issues. So if you know about them, let’s talk about them.
The package manager took a year and a half to implement. The rest after that was stabilizing HaikuPorts and getting automated package builds to work, which would have been just as much an issue on any package manager at all. So I guess I don’t know what you are referring to here.