Dpkg-haiku. Debian package management for Haiku (working port)

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.


I use ffmpeg exclusively in terminal to convert media files.

1 Like

@extrowerk, sorry, I didn’t count you as an “end user”, count you more of a “pro user” :wink:

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.

1 Like

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 :slight_smile:

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 :frowning:

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:

  • scripts in the package: preinst, postinst, prerm, postrm
  • division of packages into sections: base, devel, doc, editors, embedded, games, graphics … etc
  • patches-packages (see info about “Replaces” in file control)

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?

  1. Haiku + packagefs + optional use dpkg-haiku for non-packaged and other folders with full write accsess.

  2. 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.

  3. 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).

1 Like

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.”

1 Like

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.

1 Like

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.

  • Edit Deskbar Application menu
  • Delete or rename the driver with errors. I do it faster than editing blacklits.
  • Free up space by removing unnecessary files (fonts, images, documents, etc.). I can not remove the package because it is “required”.
  • Full bfs disk access from Linux. Specify the path with the library for cross-compilation.
  • I just want access to the whole system. To temporarily remove, move the library (system). Try something and bring it back. I don’t want to edit the blacklist every time in StyleEdit.

Perfectly. This means that dpkg has all the necessary functions and can replace hpkg if necessary.

  • dpkg can install files in any folder on the disk (including /)
  • deb can be unpacked in any OS. deb is a regular archive. All OS have these archivers
  • deb is distributed and has a lot of utilities that work with it.
  • deb has just another ideology

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 theroot 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

1 Like

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.

1 Like