Public repo with package manager

Zilog80 · 2026-06-17T16:09:54+00:00

Amazing initiative. Are all the apps banned by the official Haiku 'gods' available in one single repo? Also, when are we getting a proper package manager like Brew? We seriously need to bypass the stupid, outdated assumptions of single devs playing dictator with official packages.

clasqm

phoudoin Regarding discuss.haiku-os.org, the forum hosted on Haiku OS project infrastructure, they stated indeed that anyone can talk about AI assisted softwares in that forum, until it's labeled as such.

Officially, yes, they did. But individual moderators are ignoring that policy statement and deleting posts in the AI specific area of the forum on the basis that they vaguely suspect that it was written by AI.

I don't even use AI in my own coding, but the sheer prejudice and abuse of power just made me withdraw from the project and rather hang out here.

We can certainly create a repository of our own. But getting it to the users' notice will be our problem. Hell will freeze over before they advertise it on this page, for example, and I do not see them adding an "AI-tainted" repository to the defaults.

phoudoin By definition, it's supposed to be about ported softwares maintained by HaikuPorts project contributors.

It hasn't been that for many years. Artpaint, Becasso, Medo, all the major native apps are on HaikuPorts. The only one that is stored with the OS on the Haiku repo is WebPositive.

phoudoin And installing software via a zip file is still possible. It needs to be really portable, as in such case no dependencies are automatically managed

Do we have anything like the AppImage format? One way would be to use the makeself script. Otherwise, a static compile should be possible? I don't know gcc well enough to judge that.

phoudoin

clasqm

We can certainly create a repository of our own. But getting it to the users' notice will be our problem.

I don't think so. Sincerely. Speaking of AI is not forbidden on the forum, so I fail to see why speaking of a third party packages repository that host and distribute third party softwares for Haiku OS would be forbidden. BeSly repostory was promoted there, so were some other third party repositories.

Plus it's not the only community channel, there is Telegram, third party web site like this very one, youtube, etc.

Last but not least, trying to promote it on the haiku-os forum is cheap, so it's easy to do it. Sure, if you create a new topic everyday to do that, it will be considered spam. But if you start a topic in which you post updates comment periodically talking about new softwares available in that repository, I don't think it will be forbidden.
It will be under Softwares > Proprietary & Others, which I find myself stupid for native softwares, but it doesn't really matter, what matter is most users could see it, and nothing does that better than a topic that keep being updated.

Hell will freeze over before they advertise it on this page, for example
and I do not see them adding an "AI-tainted" repository to the defaults.

This could be less probable, I agree. The web site is mostly frozen indeed. So some effort has to be done by someone to promote to the audience the existence of a alternative repository with such AI tainted softwares, then. That promotion won't happens by magic, I agree.

It hasn't been that for many years. Artpaint, Becasso, Medo, all the major native apps are on HaikuPorts.
The only one that is stored with the OS on the Haiku repo is WebPositive.

Sure. But, yet, statistically most of packages from HaikuPorts are actual ports, not packages of native stuffs.
Anyway, that's not the real issue, the real issue is the haiku-os.org own its package repository, and therefore decide what's the rules to use it. While what they should accept or not is debatable, the fact that as owner (and paying the cost for that infrastructure) they have the final word is not debatable. Their current position about AI assisted software packages may change in the future, who knows, but currently if they say no, well, then you have to find a alternative, ranting about them enforcing their rules on their own infrastructure and their own online service is pointless, what is not is showing that there is a demand for distribute such softwares and maybe they should reconsider their position.
But fighting their rights to decide at their discretion on what they owns is a lost battle.

Do we have anything like the AppImage format?

A portable zip file with co-located "libs" and/or "add-ons" folder(s) to the app, so that every dependency libs or add-ons are also distributed along the app. But if there is a lot a such depencencies, the zipfile will be large, and you will have to manage the upgrade of libs and cross-dependencies between these libs each time you need to upgrade of of them.
The storage space on the user machine will also be bigger, as often these libs will be also present in another portable app, and even installed by some package too.

One way would be to use the makeself script.

Same issue, plus easy target for virus and hack.

Otherwise, a static compile should be possible? I don't know gcc well enough to judge that.

Not all external libs are available a static one. Starting with the obvious ones, the ones from Haiku-OS API, which are mostly available in .so only. Sure, one can try to build them as static lib version, but beware, some could be tricky or, worse, could rely on being dynamic lib. Add-ons, for instance, needs it.

phoudoin

ilfelice

But we have different interpretations of "reusing". If one has to setup and maintain a separate repo, then
that's duplicate effort to me.

You don't expect to be free to present your product on a shelf of a store who disagree to distribute your product. The only viable solution is then to either find another store accepting to distribute your product or setup your own distribution platform. With digital products, it's far more easier than with physical ones.

I'm not saying I'm agreeing or not with the Haiku-OS project rules, what I'm saying is they're entitled to set the rules on their own infrastructure, and you can't expect to be freely using their infrastructure while not respecting their rules.

It's not fully duplicate effort, as it's not only setup a second package repository, it's also getting ruling power on what can be distributed on it. This second part give you something you didn't have before.

I don't know what you are referring to "wanting to get something without effort".
We are contributing to the Haiku community with native apps that have never existed before.

Developing is one part. Distributing is another. Otherwise we won't have this very discussion, right?
Here, the issue is not developing, it's about distributing and reaching the highest audience possible.
It's not part of developing a software, but it is part of distributing a software to potential users in a way they will find it convenient to find, to install, to uninstall, and to get support if needed.

I'm not saying developing software with AI is not a contribution or needs no effort. What's I'm saying is AI doesn't help you to distribute software (yet), and therefore you rely on either conform with pre-existing distribution channel(s) rules or setup your own. Expecting not having to conform to existing distribution channel(s) rules because you don't want neither to accept their conditions nor setup your own distribution channel is what I call "wanting to get something without effort".

Atomozero

I'm coming in well into this thread, but it looks like most of the reasoning has already been worked out by you, and in a direction I share. phoudoin put it well with the store-shelf analogy: if a shelf won't carry your product, the sensible move isn't to fight over the shelf, it's to set up your own distribution. That's exactly what I've been working on for a while. It's called spritz, and it's not just an HPKG repo: it's a federated catalog plus installer.
The problem it targets is the one this thread keeps circling. HaikuDepot only shows what comes through HaikuPorts. Everything else stays invisible unless you already know the URL: apps published straight in GitHub releases, third-party repos like BeSly, Fat Elk, Clasqm, the old BeOS archives. BeOS had BeBits for exactly this, and Haiku never rebuilt it. spritz is a single searchable index of the software sources that already exist, always pointing back to the original authors instead of re-hosting their binaries.
Let me be clear about what it is: an independent, self-standing project, born and growing outside the haiku-os.org infrastructure. It asks no one's permission to exist and depends on no one else's decisions to move forward. As phoudoin said, setting up your own isn't just duplicate effort, it's gaining the power to decide your own rules, and that power wasn't there before. That said, it's built in an additive spirit, not as a rival. It leans on HaikuPorts: dependencies are resolved by the system solver against the repos you already have, and every app manifest (a cichéto, just a small YAML file, no haikuporter recipe) can declare a bridge to its HaikuPorts package when one exists, which kills the fragmentation worry at the root. The relationship is AUR to the official Arch repos, the nursery and not the competitor. Part of the value flows back to HaikuPorts by design.
Anyone can publish a tap of these manifests, a bàcaro, in about five minutes. And each app can carry more than one release channel: a locked, hash-pinned stable, and an ombra that follows the author's latest release as it lands. That second one is the thing HaikuPorts can't do by nature, the gap dcbeckman and ilfelice were pointing at.
On the visibility point clasqm raised: phoudoin is right, BeSly was talked about on the official forum and nobody banned it, so a third-party repo can be promoted there as well as anywhere else. Then there's Telegram, the community sites, YouTube. The distribution channels exist, you just have to use them.
Current status: the registry server is implemented and tested end to end (catalog, search, accounts, the resolve endpoint the daemon will call). What's missing is the web frontend and the native Haiku daemon that closes the loop. Those are the two open pieces, and to clasqm's bus-factor point I'd rather not be the only one holding them. And here's the real ambition: if we find the right collaborators and the project matures, there's nothing stopping spritz from one day shipping inside a distribution as the install front in place of HaikuDepot. Not as a slight to anyone, but because a native client that aggregates every source is simply what Haiku is missing. For now that's an honest possibility on the table, not a promise.
A personal note: I designed this system myself, and I'm not a programmer by training. I built it with the tools I have, and that's exactly the point. If an architecture like this can stand up starting from where I start, imagine what comes out once people who code for a living get their hands on it.
The repo isn't public yet. I want to clear the security tests first, so I'm not shipping something with holes in it. I'll run them this weekend, kids permitting, and if it passes I'll put it up in the next few days.
Shaka444, HaikuApps.org could slot right into this as one of the sources, or as the web front. Happy to talk specifics. If anyone wants in on the frontend or the daemon, that's the place to jump.

phoudoin

Atomozero

HaikuDepot only shows what comes through HaikuPorts.

No. HaikuDepot shows what all enabled packages repositories have in their catalogs.
The difference is not in HaikuDepot app, it's in default enabled packages repositories out of the box of a fresh Haiku OS machine : only haiku and haikuports repositories are pre-registered and enabled, indeed. We used to have also BeSly and Clasqm's repositories too once (or maybe that was just me who added manually, can't remember).

BeOS had BeBits for exactly this,

Just remember that BeBits was not created nor provided by Be Inc, editor of BeOS, it was from a third party.

and Haiku never rebuilt it.

Haiku OS project had already to rebuilt BeOS, it was/still is a daunted task, as for BeBits, there is a opportunity since long for third party to jump in and fill a need that the project can't (or don't want, whatever the reason) to respond to

spritz is a single searchable index of the software sources that already exist, always pointing
back to the original authors instead of re-hosting their binaries.

Something like a "proxy" HPKG repository, updating and exposing a catalog of all packages availables, whatever the way the technology to distribute it (download directly from an URL, or via a real HPKG repository), but for downloading the package itself acting like a proxy (ideally with a file checksum check to be sure to distribute genuine content) ?

Or do you plan to need to have a custom gui app for Haiku to access it and the default, HaikuDepot, can't be used with it?

Having a web UI available is great, too, yes, but the end user have first to find how to download a "store" app to be able to access it when the objective of this "store" is to be a meta/proxy store of all available packages for Haiku-OS, it raises the cost of end user entry. Please consider a solution that will works as-is with the default app, needing only to add one repo URL either manually or eventually being accepted to be part of defaults repositories one day. After all, Be Inc. promote openly the BeBits platform while they have their own package installer (mostly only used by few earlier proprietary editors, like GoBe Productive for instance), called SoftwarePackage IIRC

KitsunePrefecture

Atomozero
I assume it wont be available via pkgman.
Yet another GUI stuff I avoid using to install if possible.

I do not understand that why you insist on Haikuports only in HaikuDepot.
I think you fear that -- it is by default -- without adding your additional repo.
It's TRUE, this way wrote @phoudoin that it needs additional effort from your side to have your repo known to end users.

All your HPKG packages would be available from your repo as it had established.
First probably experienced users would be use it.
But if you are clever and for a user problem you have an app or something, you can add instruction how to add your repo to the repository list.
Also you can have an applet, which adds all alternative repos to Haiku. Then you can implying the user to use that if they do not want to use a terminal command.
I just nowadays started to use Repository applet in Haiku to temporarily disable Besly in my Nightly, to be able to update packages from other ones.

Atomozero

phoudoin No. HaikuDepot shows what all enabled packages repositories have in their catalogs.

You're right, and thanks for the correction. My phrasing was sloppy: HaikuDepot shows whatever the enabled repos carry, and out of the box that's just haiku and haikuports. The point was never the app, it was exactly that default.

phoudoin Just remember that BeBits was not created nor provided by Be Inc, editor of BeOS, it was from a third party.

And that's precisely the point in favor. It was a third party filling a gap the OS vendor didn't cover. That's the same position we're in now, and I don't see it as a problem but as the opportunity you describe right after.

phoudoin Something like a "proxy" HPKG repository... but for downloading the package itself acting like a proxy (ideally with a file checksum check)?

You've read it right, at its core it's a meta-catalog. It aggregates sources that already exist, including ones that aren't HPKG repos at all, like apps published straight in GitHub releases. Checksums are mandatory on the locked channels and verified on download, so genuine-content checking is part of the design from the start, not bolted on. The one thing beyond a pure proxy is the ombra channel, which follows the author's latest release as it lands, the thing a static HPKG repo can't do by nature.

phoudoin Or do you plan to need to have a custom gui app for Haiku to access it and the default, HaikuDepot, can't be used with it? Please consider a solution that will works as-is with the default app.

This is the right thing to push on, and I want to take it seriously rather than wave it away. The plan is two layers. The subset that are real hpkg files on the locked stable channel I want to expose as a plain HPKG repo too, so you just add one URL in HaikuDepot and it works as-is, no custom app. The native client is only needed for the extra: the ombra channel, the non-hpkg sources, and the remote "queue an install from your browser" thing. The default app stays the entry point for the common case, exactly as you're asking.

And here's where you know more than I do, so I'd rather ask than guess: does HaikuDepot handle a repo whose individual hpkg files live at arbitrary URLs, like GitHub release assets, or does it expect every package under the same repo base URL? If arbitrary URLs work, the plain-repo layer is almost free. If not, I'd need to mirror the stable hpkg files, which is doable but cuts against the "always point back to the author" principle a bit.

phoudoin After all, Be Inc. promote openly the BeBits platform while they have their own package installer.

Exactly, and that's the model I'm looking at: the third-party catalog and the system installer coexist, they don't exclude each other. spritz wants to sit in that same relationship, not replacing HaikuDepot but feeding it the stuff it doesn't see today.

I'm fried tonight, so I hope Claude translated all this correctly 😃

clasqm

Atomozero does it expect every package under the same repo base URL?

From my hosting-a-repo days, yes, this is pretty much how it worked.

phoudoin

Atomozero

the one thing beyond a pure proxy is the ombra channel, which follows the author's latest release as it lands,
the thing a static HPKG repo can't do by nature.

Depends. The nightly hpkg.haiku-os.org/haiku/master/<arch>current is tytpically demonstrate it's possible.
The issue here is you need to automatize the detection of latest/head/master changes of external projects and rebuild the packages (with some automatic versioning) + update the catalog of your repo.

It's goes way beyond the scope of "hosting" an HPKG repository, here it's more about the whole infrastructure that track and auto rebuild any package which has changes. That's typically what does the build farm of Haiku-OS, and what does the haikuports project buildbot too.

does HaikuDepot handle a repo whose individual hpkg files live at arbitrary URLs, like GitHub release assets,
or does it expect every package under the same repo base URL?

No, all packages exposed by the catalog of an HPKG repository are to be accessible from the base repository URL + the package file name.

That's why I speak about proxy behavior, if you don't want to host all files in the repository but instead act as a proxy to access packages hosted on external URLs. your repo can handle the URL GET request on a .hpkg declared as being available in the catalog, but in fact download it from remote, external URL like a github release URL or a custom web site, maybe with some caching to avoid doing it too often. What matter is that for every package name declared in the catalog file of the repository, a request base URL + package file name to download it over HTTPS will works.

If you have locally a way in the server to detect which request will land to a local package file and which will needs to act as a proxy, it's possible to do. But it won't come by default with a basic https web server software, it will needs to be a more dynamic, custom webapp doing it.

If you don't find it already, you may find more details about HPKG repository expected interface here:
https://www.haiku-os.org/docs/develop/packages/Infrastructure.html

If arbitrary URLs work, the plain-repo layer is almost free. If not, I'd need to mirror the stable hpkg files, which is doable but cuts against the "always point back to the author" principle a bit.

clasqm

phoudoin Part of why I've sign-up here is actually to test if the community split can be healed in the future, maybe helping at that, and also test if every opinion can be freely expressed here or if not being fully aligned with your own position, being the guy being that whole desktoponfire.com, will bring me the same rejection or moderation issue too, but here.

AFAIK, right now that is entirely up to @Atomozero. We've been up for all of two weeks, so we haven't really got a formal structure set up yet 😀. But here is an informal, preliminary test:

Question 1: Are you capable of typing the letters A and I without automatically typing "slop" afterwards?

.... Going through @phoudoin's posts ....

Yeah, you're fine.

KitsunePrefecture

Shaka444
Ahoy @Shaka444 ,

For scripts I think it's a bit too much to create packages to share them.
If you have a git repo somewhere that is available for clone a directory or file -- that is surely enough.
I am not a developer, but and I have no intentionally a Github account, but when I learnt that I can copy a file from Github
files directly to my machine exactly there where I want ,and immediately, instead of after to ripping off its content using editorial commands to put its content into a local text file, later I might convert into a more sophisticated type of file -- I was releaved.
Install git
and after issue a
git clone <URL>
is not a burden or very hard to do it.

To package shell scripts it's better if you have some more (dozens), that can be deployed instantly and altogether this way.

clasqm

KitsunePrefecture

Yes, cloning a git repository gets the script onto your site. But it is now in a location like /boot/Storage/git/mygreatscripts/bin. and there are issues

To make that script available system-wide, it needs to be copied or symlinked to somewhere in the PATH
Is the shebang line #! /boot/bin/interpreter correct? Keep in mind that scripts coming from Linux expect to see /usr
Does the script need a chmod +x before it can be run?

All of which is perfectly doable by anyone with a bit of experience. But you are going to get a lot of mail from complete newbies wanting to know why it doesn't work.

Now put the script in a package. Newbie downloads package, opens it and clicks on Install. Done.

KitsunePrefecture

phoudoin

Me also joined, to see, especially if here are developers
who may have time to listen an idea
and after discussing, fine tuning,
it may conlude in a working app on Haiku - anytime soon --
not perfect in all way, but usable. In this case I do not care if any AI aid at all or how many AI aid was used in it to be built.

Haiku needs a issue reporting app that does not need to have Github account and Codeberg account and whatever else the apps, libraries, drivers can be found to upload and may its developers to want make us to use for issue reporting.

This is also a planning point of view if an another repo planned.

I avoid using Github Issue report as I have to use its Web surface, I have to deal with it needs an account, I need to find where I can report, how I can get answer, as HaikuPorts have many stuff provided altogether.
Is there different Issue pages? Is there only one ?
I am not a developer. If I learnt that, then there are stuff on Codeberg too. I assume I need accounts there also to report.
What can I do with stuff I downloaded from SourceForge ?

Me and other users can add another repo to the system.

clasqm

KitsunePrefecture Haiku needs a issue reporting app that does not need to have Github account and Codeberg account and whatever else the apps, libraries, drivers can be found to upload and may its developers to want make us to use for issue reporting.

I agree. The self-appointed ticket police on the Haiku forum are very annoying, even more than the "we already have a recipe for that, but whatsisname won't let us merge it" responses.

KitsunePrefecture

clasqm
Well I had not thought one use any script from the internet, not just one that would come also from another Haiku user 😃
I agree, some might try to use any Github or Codeberg stuff without checking connection /compatibility to Haiku.

In case execution right addition, that needed, you are right - I forgot to mention that.

And of course, I had not mentioned I download the file/directory for git into my
~/<ALL toying project directory>/<whateverNEWstuffDirectory/
After all needed preparation finished and the result script file/new binary READY, I copy them into
/boot/home/config/non-packages/bin
that is on the $PATH in the env (environment).

Many copied to an additional BFS thumbdrive to have a backup/archive.

KitsunePrefecture

clasqm
Ahoy I informed lelldorin in privi about services down on Besly on 19th of June , on the next day first I experienced first.
On 24th of June finally I asked back about its seriousness of the issue as services had been down yet.
lorglas confirmed (who does the hosting stuff there ) : the fault at their service provider. This way those still down until now.

Unfortunately their bug tracking service hosted on the same infrastructure, so now we cannot follow the progress, just check the availability of the services from a browser. The host itself could be pinged. Apache reports back error.

Kevin

I love the idea of a second repo that's open to AI/LLM code. I'd vote for sticking with the hpkg format and not reinventing the wheel. Claude has no issues making a hpkg. And being able to add the repo to HaikuDepot would make it easy for users.

My only concern is how to keep the repo alive for years. As pointed out before, real life happens and people come and go.

Shaka444

Kevin My only concern is how to keep the repo alive for years. As pointed out before, real life happens and people come and go.

Agreed.

So we setup an "App Store" online and a repo link. (and maybe a little applet to add our repo to HaikuDepot).

Developers have an account that lets them add their app description, pictures and a link to their source code.

A team of "Maintainers" builds the apps from the source and upload it to the app store-
this can be completely automated with a script or a YAB applet ( git clone etc.. "MyGreatApp" ; make bla bla bla.. ; upload with "scp /path/file username@remotehost:/path/directory" etc.. The maintainers just provides the storage space and processing power- download/build/upload can be done unattended in the background. You would only have to step in if the build failed.

Having a team of maintainers ensures that we avoid the "death trap" :-) (people dying, leaving project..)

The easier we make the clone/build/post process, the more volunteers we'll get.

phoudoin

phoudoin
Sorry for the leftover quoted text at the end of my previous comment.

Zardshard

Oh nice, you're working on a new package repository! I personally like the approach of labeling AI-assisted code and then letting the user decide whether they want it or not. It's a divisive issue and not everybody will agree with each other. I've seen people vehemently against it and people vehemently for it. I think the best way forward is having these solutions that enable the user to decide for themselves what they want. Definitely feel free to advertise the new repo on discuss.haiku-os.org when it's ready so that users know about it!

Atomozero

Zardshard I personally like the approach of labeling AI-assisted code and then letting the user decide whether they want it or not.

Thanks Zardshard, that means a lot. The user deciding is the core, agreed. One thing I'll be upfront about, because it's a real design choice: the AI label only shows up when the author switches it on. There's no "undeclared" tag, no default suspicion, no system guessing on anyone's behalf. So the filter isn't airtight, and I'd rather say that plainly than pretend otherwise.

The bet is that in a place where labeling gets you respect instead of an interrogation, most authors will just do it. The old forum's witch-hunt pushed people to hide; remove the hunt and you get more honesty, not less. I'd rather earn the labels than police them.

Zardshard Definitely feel free to advertise the new repo on discuss.haiku-os.org when it's ready so that users know about it!

I appreciate the nudge, and the repo URL will be open for anyone to share there. But I don't think I'll be reactivating my account or opening a new one over there for now. It's still an open wound, and I'd rather be honest about that than pretend I'm over it. The software is welcome there even if I'm not the one carrying it in.

phoudoin

Shaka444

It can be even simpler : the developers just does themselves the build stage and submit a new (version of) .hpkg of their software, giving an URL to access it, the meta data (version number, architecture, maybe category) via a web interface of the repository, and that it. Like it used to be for BeBits.

In a second phase, add some web API to allow developpers to do that programmatically, like for instance in their own gitlal/github/whatever CI pipeline, so they can automatize the submission of their hpkg file, including a new version, including latest version.

If you have to rely on a team of people to do that for them, it won't works long.
Without the automatisation, Haikuports will have collapse on its own weight, its already a notable effort to just maintains the recipes code which allow the automatized build infrastructure de (re)build automatically a large number of packages.

Move this on each software developer elbows: either they wants to do it manually, only when they want to push a new version of their software hpkg, or they can use some web API (Open API/REST) to integrate it automatically from their own automatized build & publish pipelines, like github's CI pipeline, gitlab's CI pipelines, etc.

« Previous Page Next Page »