I am interested in learning more about the HaikuDepot, specifically about how to host custom repositories. Is there any documentation or help that someone can point me to related to setting something like this up?
I have a few basic reasons for wanting to do this:
A non-public repository that would serve as a self-service for IT if Haiku was used in a company setting where internal tools were hosted for employees.
A non-public repository setup by a school for students if Haiku was used in an education setting. This would serve as a way for students to browse available programs.
For a children-focused setup where the repository would be filled with educational games and other children-focused apps.
In a setup like this, the other repositories may be removed to help avoid non-approved apps to be installed on managed devices.
You can define that repo you want to be available, but the user can add one too, because pkgman can not set to admin only at the momrent (iirc) and not remove, because you need it to install packages.
One important thing to note here is that package repos are separate from the server that HaikuDepot uses for some of its data, such as user reviews and screenshots. I haven’t delved deeply into this yet, but it might be nice if the HaikuDepot server API was more explicitly documented and easy to replicate. It might already be a simple REST API, but I am not sure.
Making new repos is easy it seems, but I don’t think anyone has made a new HaikuDepot server.
I think to fully do what you want OneRyan, you would need both.
A good one to raise @leavengood but there is no need to create a new HaikuDepotServer (HDS).
HDS is able to cope with multiple repositories already. Once your repository is served, ask somebody on the Haiku system administrators’ list [1] to add your repository in; something they will be able to do in ~2-3 mins in the HDS web user interface. When they do this, your repository will be allocated a unique code in HDS. Other repositories can be seen here [3]. If you are deploying to a mirrored system, supply each of the mirrors together with the country where the mirror resides.
When you update your repository, HDS provides APIs that are able to trigger HDS to pull in fresh data from your repository [2]; otherwise it happens periodically on a poll. For this you will require the HDS code for your repository.
If you have any trouble please ask on the HaikuDepotServer mailing list [4].
Please note that the HaikuPorts currently has a network-related problem importing and that is being worked on [5].
Tutorial is the same, but it appears that .zip file is an older one. Some time ago I have updated the script to automatically generate package listings while creating the repo. This version is on my server, linked from guide on haiku-os.org.
They have explicitly asked how to have a non-public (i.e. private) repository setup for internal needs. And they want to control what applications can be installed so they need to be able to locally remove and prevent re-addition of any repositories deemed unacceptable…
Having to deal directly with the OS developers simply to add a repository doesn’t make a lot of sense when in the hypothetical examples any entity (company, school, organization) could want their own (under their own control). If that repository is useful with a larger group of similar entities that might be okay, but it wouldn’t satisfy the non-public issue since it would have to be public to be of benefit that way. A password might be amenable as a kind of security, but how would such an arrangement actually work for a system serving a repository locally without access to the outside world? Would HDS even be able to specify how to locate and access the internal server?
Hi @Istarian; Yes it looks like I did miss the point of the original post! Thanks.
However it’s actually not too difficult to run another HaikuDepotServer (HDS) as well. To get the desktop application to communicate with a specific HDS, run it from the command line;
It would be possible to add a “preferences” item for setting this value. If you are switching between HDS-s, you can simply delete the following directory to drop its cache;
~/config/cache/HaikuDepot
Instructions for the deployment of HDS are there, but there seems to be some problem with that page of the documentation (I will fix it) but it is not too hard to achieve.
