Nope. There is actually a report that says exactly what is broken. E.g. https://eu.hpkg.haiku-os.org/haikuports/master/x86_64/current/repo_consistency.txt
Sometimes people do not get around to fixing these, but hey, it’s there.
This is entirely a problem with HaikuDepot (and a number of changes to HaikuDepot have been merged in the last few days that greatly improve this situation.) Running pkgman search
, for example, shows how fast the package manager is underneath truly.
It took a lot of time to develop, sure. But that it “continues to drain”? Where do you see this?
In the “old way”, if you tested a driver that broke your system, you had to boot into a separate install to remove/replace it. In the new way, you just set “Disable user add-ons” in the bootloader, and you are done.
In the “new way” (with the exception of “boot” drivers like USB, SCSI, etc.), you just send someone the driver and tell them where to put it in non-packaged, like before. Or you can send them a single package (if made properly, it needs a “system” flag) and it will also work. Or you can send someone an entire “haiku.hpkg” (works even for “boot” drivers.)
Is the new way trickier for developers? Sometimes. But personally I prefer being able to recover my system without fiddling around for a pen drive or something.
Some other upsides Zenja did not mention, that I also like:
- Being able to change/add/remove what packages are installed, without having the system running.
- No “installed files database” to get corrupted (as every other package manager does, and yes, this can happen…)
- Packages are stored compressed, and take up less space on disk, while the rest of the filesystem is uncompressed.
I don’t really know how you can say that booting into a previous state has “no use” for you. How much do you run Haiku nightly builds? It is an invaluable feature there, as any tester or user of them will tell you. (Sometimes it is useful even when just taking software updates, too.)
You continue to claim that “no real common use case benefit” has come from these complexities, but plenty of users (and developers – and let’s not forget we developers are also users!) disagree.