I have split the discussion into its own thread, as it became quite off-topic for the “New in HaikuDepot” thread. Don’t hesitate to create new threads before getting too much off-topic. It’s easier to find the info someone’s looking for that way. Thanks. --Humdinger
Always fantastic to get new apps! Cannot be stated enough how much effort goes into bringing software from one ecosystem to another
Instead of creating a whole new thread for this, I figured I’d ask right here - who would I contact about posting to HaikuDepot? I’ve been patching & repackaging a lot of source-available apps from x86_gcc2 to work under the x86_64 build, and would like to share them!
Is there any benefit to simply starting another repo (i.e., to help ease traffic from the main Depot), or would that just be unnecessary fragmentation?
[quote=“officerwafl, post:6, topic:4169”]
Who would I contact about posting to HaikuDepot? I’ve been patching & repackaging a lot of source-available apps from x86_gcc2 to work under the x86_64 build, and would like to share them![/quote]
The HaikuDepot app currently only shows (part of) what’s in the haikuports repo; the other repos are available thru ‘pkgman’ in the Terminal. To get into haikuports, you’ll have to submit a haikuporter recipe, see their wiki. With it the package can be rebuild when needed, in the near future automaticall by buildbots.
If you want to distribute already built packages, you can start your own or ask the guys running the various package repos to include them for you. Especially with ported software, there’s a potential for conflict of the dependencies (libs etc.), so managing a repo takes a bit of curating or things may go subtly wrong with some packages. Mixing packages from one repo with their depencies from another could be a problem as I understand it. I don’t know if there has been an example of that in the past.
That’s not to scare you off, just for information should the repo manager ask you to repack using certain versions of a dependency etc.
I don’t think we’re at the limits quite yet.
Though, asking an already established repo to host your packages would make your apps more easily discoverable, as people would have to add your repo manually first.
Okay … speaking under correction, but I believe all the existing 3rd-party repos are primarily targeting gcc2-hybrid. There certainly is a space out there for a repo that concentrates on pure x86_64. bbjimmy has a tutorial on how to set it up: http://fatelk.com/repo/repo.html. IIRC Lelldorin’s repo has a GUI app to manage a repo.
X86_64 is in a bit of a chicken-and-egg situation IMHO. Nobody is writing or porting for it because it is not going to be the official format of the next release, but it is not going to be the format of a next release unless there is overwhelming user demand and plenty of apps.
But you don’t really NEED a repo right away. I would suggest that at first, you simply post your HPKGs to your website to see if there is a demand for what you have in mind. Get people to download the HPKG and double-click to install. The smaller repos generally have a web interface of their own in addition to being available via the pkgman command, Haikudepot app and the Haikudepot web app. e.g http://fatelk.com/repo/ As the number of packages in your repo grows, that is no longer maintainable. Trust me, I’ve tried.
You could also ask the existing user community what they think of the idea on the Haiku Facebook group: https://www.facebook.com/groups/haikuosgroup - There are people there who do not necessarily read this forum.
Then you can decide whether to start your own repo or to work via haikuports. Or both. For example, you could use your own repo as a testing branch before you commit to haikuports. No, you don’t have to do that, I’m just showing that there’s considerable flexibility in the system.
The best place to find the existing repo managers and ask for advice is BeShare. Some of us are more territorial than others. That’s not a point of criticism, BTW. You are most welcome to download my entire repo and produce x86_64 versions of everything that includes source code. But some of the others prefer a little more control over where their material ends up, so ask first.
One thing we are pretty good about is advertising each others’ repos on our websites, so I don’t think discoverability would be a problem.
I should add that there is work in progress to advertise the repos directly in HaikuDepot (for the ones which are already listed on the HaikuDepot server website).
On the Haiku developer side (well or at least from my point of view):
On one side, managing the haikuports repo ourselves is more work than we can afford, and people who can contribute to Haiku shouldn’t spend most of their time managing that, so, having other repos taking care of that is great.
On the other side, leaving “random” people in control of the repos sounds sometimes a bit worrying. We need to get used to that loss of control and rely on the reviews/rating on the HaikuDepot app to let people know which packages are good.
Thanks for the feedback, everyone! I think what I’ll do for now is convert as many apps as I find to be useful to 64 bit, host them through my site, and see how it goes.
On the rift between 32 and 64 bit - has anyone been working on a compat library for running GCC4 (x86) apps on x86_64?
Not to cram too many questions into a single message again, but I also saw on another thread, a while ago, some murmors of peer-to-peer package sharing (not just through the magnificent BeShare, but as sort of a Torrented Depot) - any news on that? I only know of Windows doing something similar in Active Directory domain scenarios, and coming from a background in Arch Linux, I loved using Powerpill to snarf the closest updates to my stuff from the AUR.
It is unfortunately not just about a “library”. The main problem is that applications and kernel will sometimes exchange memory addresses. 32-bit apps work in a 32-bit address space, but in this case the kernel will work with a 64-bit address space. This needs specific support on the kernel side to “unfold” the pointer to full 64-bit physical addresses, and “fold” them to 32-bit when giving them back to the application.
That being said, such a change would allow running legacy apps on a gcc5/x86_64 system, allowing its use as the main architecture whenever Haiku decides to do that (probably some time after R1 is out). If someone is interested in implementing this, Im sure we can find some Haiku devs to “mentor” the work (provide implementation hints and review patches).
