dpkg-haiku is the Debian package management port for Haiku.
Screenshots below. The main functionality works (install, remove, list), but not everything has been verified.
Installing bash from the deb package (the bash-deb name was made specifically to distinguish it from the system one)
Remove bash from system
Currently being tested in non-packaged folders. This does not violate the haiku system.
But why? Whatâs wrong with Haikuâs package management system? Dpkg is so much less efficient and worse to work with.
It does not violate the package manager itself, but it certainly violates the Haiku philosophyâŚ
I donât understand the usecase for using deb/dpkg inside of Haiku (Unless you want to extract, query or generate deb files in Haiku without Linux).
I do not expect this to be included as a system compnent but only as a third-party one, but regardless, this throws away the years of work on Haikuâs own package manager and hpkg which is arguably superior to this.
Good day,
I could think of an usecase⌠Have some sort of HSL (Haiku Subsystem for Linux) like the one Windows has.
Anyway, being Haiku POSIX compliant (to a certain extent) it might be more optimal to increase POSIX compliance and add functionality to Haikuâs bash shell, though âend usersâ donât really care about these dev stuff. I have yet to see an âend userâ using the terminal for anything.
As an exercise I presume itâs a good one. This might mean that other package formats could coexist with the preferred, native HPKG, and presumably could help some apps be available on Haiku. Thinking about @probonoâs AppImage. Just guessing.
Regards,
RR
I use ffmpeg exclusively in terminal to convert media files.
Many things but compromises were made to get to where we are. So lets not add to that old discussion ad nauseum. Some people would prefer things a different way, this is obvious enough, some enough to even implement alternative package management systems.
Thatâs debatable. You could argue that Haikuâs current package management severely violates BeOS philosophy⌠but whatâs the point. Somewhere along the way Haiku became rolling release, which is directly counter to BeOS/Haiku philosophy, however most of the issues were mitigated by the packagefs design. Someone obviously cared enough to bother to implement this though, that doesnât give anyone the right to tear them down.
I would tend to agree that dpkg is probably the wrong choice since its slower and more complex than alternatives⌠pacman from Arch and just using haikuports as is or extended to build packages for Arch might make more sense IMO. A robust Linux like package management system would also have to handle files that existed in old packages but not in new ones as well⌠as well as config file updates etcâŚ
At this point I think a packagefs-less Haiku is imperative for low end machines, yes it means you loose features but they are features that arenât part of BeOS so who cares on those old machines? The fact is packagefs requires more memory because it is doing more stuff, stuff that isnât imperative to have and that sometimes gets in the way. Iâd be interested in hearing the logic behind choosing deb over others actuallyâŚ
Asking âBut whyâŚâ seems rather unempatheic⌠considering it is a question continually asked to any developer or user of Haiku. Especially considering you are very much in the know, on peopleâs issues with package management.
Iâll add to this that there is a sunk cost fallacy going on there, where people seem to think that because so much effort when into pacakgefs that it is absolutely the only right answer⌠the fact is haikuports + a simple package manager would have taken a small fraction of the time to implement and provided 90% of the features with much lower runtime overhead.
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.
If people want to get haiku alive and be a good system with futur, it need to be runable on current hardware. I does not want a new Amiga.
At first, I looked at the FreeBSD package manager. The choice was based on the license and thoughts that it will be simple. It contained many BSD-specific functions. And I abandoned him 
I use debian based linux more, so I just decided to build dpkg. I was surprised that there is no hardlink support in bfs. I hope this will be add to bfs2 in the future.
I never worked Arch, perhaps their package management system is better.
Please do not consider the alternative package system as a request to remove packagefs from Haiku. PackageFS is an excellent development with its own philosophy.
HaikuPort is a good working system that can be made to pack into other packages. It is a pity that I do not know the Python language 
Can Haiku be used without packagefs? Yes, if I need it. I agree that it is not convenient to update the system. Therefore, I need a classic version of the package manager.
I like to have full write access to the entire system. As for security, I would like to have one regular user and one superuser in Haiku.
What I like about dpkg:
All this allows you to make flexible packages, generate settings files after installation, remove all tails and settings after removing a package.
How can this be used in the future?
Haiku + packagefs + optional use dpkg-haiku for non-packaged and other folders with full write accsess.
Haiku core + packagefs + all other packaes in deb.
Use packagefs only for core Haiku packages. Such a system may be called Haiku, since nothing removes from the system. It only adds programs in its own way.
Hardcore version. All in deb.
But⌠you donât need to know Python to write recipes? Recipes themselves are just shell scripts.
Okay, but why do you need it? What use-case do you have that requires it?
HPKG has pre-install and post-install scripts, and HaikuPorts uses these already (e.g. KDE recipes need them.) Pre-remove and post-remove are in a Gerrit change that hopefully will be merged before too long. So ⌠I donât know how dpkg is somehow better on this front?
We do this in HaikuPorts/HaikuDepot alreadyâŚ
Yes, Haiku packages do all of this, and HaikuPorts recipes take advantage of this when it makes sense to. So I donât know what you think dpkg has here that we donât.
Actually bother to read his reply⌠he wasnât talking about writing recipes but extending Haikuports to generate alternative package types, that probably would be trivial though.
Oh I dunno not blow 200MB of ram on packgefs⌠for a base install. Irrelevant for machines with over 1GB⌠of course. Allow actually modifying things that are installed⌠granted this is frowned upon by most package managers anyway as you are breaking the install. Be a bit more open minded and youâll find you wonât be arguing with people that have different objectives (that actually arenât even interfering with you to begin with).
Right, it seems I did misread that. Modifying HaikuPorter wouldnât be trivial. Writing an alternative tool to make dpkgs or whatever else may not be as difficult as one might expect.
Itâs not 200MB. The whole system uses 230MB, and in s40inâs âno packagefsâ builds it uses 120MB. So itâs 110MB at absolute most; and if I recall correctly, a good amount of this was âcachedâ memory which means it will get freed when it is actually needed.
I also note that even the most light-weight of Linux desktops these days (XFCE) needs 400MB at idle after boot. So while we can make improvements for certain, we are far and away better the competition as it is.
It has time and again been asked: what is the actual use-case for this? As you note, package managers on other systems highly discourage it.
But thatâs what I am trying to do here: Iâm trying to determine what the use-case is so we can make packagefs adequate for it, instead of having them say âwell, packagefs does not fit my needs, so I need to engineer something totally different.â
Actually, last time I checked it was used memory, not cached, unfortunately.
Fair point for sure. The more people can stay on stock Haiku the better Iâm not a fan of forks any more than you are, that said Iâm not against them either, an occasional rare fork or utilities that conflict with the usual use of Haiku that ends up getting merged back in as improvements can be beneficial.
Bone stock install of hrev53259+3 is using 290MB and has 419MB in use including cache (what is the +3 means the build is 3 revs ahead of the last hrev tag)?
Edit downloaded a fresh install of 53277 and it is sitting at 236MB on the desktop used which is much better but still quite high. Interestingly used + caches are still at 417MB. pkgman full-sync works⌠from 53279 but HaikuDepot is still doing this:
That looks like a HaikuDepot bug⌠It still is really not so reliable with how it handles its internal data.
Shouldnât that be handled by a library shared by pkgman and HaikuDepot? Obviously HaikuDepot does more stuff, like show reviews and icons etc⌠but this looks like itâs having an issue with repo data itself. Anyway kinda OT.
Perfectly. This means that dpkg has all the necessary functions and can replace hpkg if necessary.
/)What is hpkg better than deb?
This is one of the reasons why I love Haiku.
I want to ask someone to make a blacklist add-on for Tracker. For virtual deletion of files directly from the tracker. And a special blacklist basket where you can recover files. I think it will be convenient for Haiku users.
And I would like users to be made as in Unix:
The username is âuserâ in the users group
The username is root in the root group
Now you are user in the gid 0 group. But there is no group with gid 0. You need to either delete the user user and leave only the root. Or do it right
If you have specific files you think do not belong to Haiku core, you can suggest them from removal or splitting out into more packages. However, I have already mentionned that I would prefer we do not do that for the Noto CJK fonts (the largest package in the default install), because I think applications written for Haiku should be able to rely on the existence of a CJK font to render text in all languages.
If we allow people to remove this, then they will make bugreports about applications not rendering some parts of the text.
As I mentionned, even if Haiku decided that it was not needed, I would add it as a dependency to all of my apps (including WebPositive) where it is possible that there is a need to display text in these languages.
So yes, it is required and this is not just to uselessly waste diskspace.
Just like you can extract dpkg files on Haiku now, you can extract hpkg files on Linux using the âpackageâ tool which is built when you compile Haiku on Linux. And if you have a cross compiler setup, you probably did this already.
deb files are not âjust a standard archiveâ, you can indeed extract them with ar then find some subdirectory with the tar with the actual data. No one does that, and instead you use dpkg to manage them.