Let’s just start by accepting that 3rd-party repositories are here to stay. Not everybody wants to work via Haikuports. Some of us like to maintain more control over what we present to the community. But we still want to give the Haiku user a unified experience that does not come across as confusing. I have been thinking of a few simple rules that will make life better for us all.
1. The primary source of Haiku software are those maintained by the Haiku project itself (for applications, currently Haikuports). 3rd-party repository maintainers will not release ported versions of software that directly compete with packages available there and will remove conflicting packages when they become available for download officially. However, maintainers may use their repositories to present “bleeding-edge” versions of their own programs.
example 1: on my repo there is a package called discount. I need it as a dependency for my own app Rondel. AFAIK there is a recipe for it but it is not available for downloading on Haikuports yet. When it does become available, I will pull that package from my repo to avoid confusion and my app will start using the official one instead.
example 2: The version of yab on the FatElk repo is usually in advance of the one on the official repos. This is acceptable, since bbjimmy is the current author of that program.
2. 3rd-party repositories will not present the same versions of applications as other repositories, unless by mutual consent between the repository maintainers. They may, however, offer substantially updated versions of an application.
example: I noticed that the GuestOne repo had been inactive for a long time and that their version of Arachnophilia was quite outdated. I therefore felt justified in porting the current version for my repo. I would not post my own port of the same version of Arachnophilia. Also, what we don’t want is a situation where I make v1.0-2, then the next day someone else adds a line to .Packageinfo and makes 1.0-3, then the next day I make 1.0-4 etc. This is not a competition!
3. 3rd-party repositories will focus on end-user applications and avoid systems software.
Explanation: It is probably not going to be possible to avoid posting library packages entirely, but try to avoid it. If you port an application with very old and obscure libraries, try putting them in /boot/system/appname/lib rather than in /boot/system/lib. Many applications will work fine that way. Rather use up a little extra HD space than screw up the entire system because your package overwrote a systems library (Yes, I know there are built-in safeguards, but why take the risk?), Speaking more generally, if you want to write systems software, you should be joining the Haiku dev team, not posting them on your own repo. IMHO anyway.
4. 3rd-party maintainers are asked to post a complete list of new and updated packages on a dedicated thread in the Haiku forums as they are uploaded.
Explanation: This will just keep the whole community, dev and user alike, in the loop to what is happening. It can be full and comprehensive, but I think it should be kept as simple as:
Hi everybody, here are new apps and updates on the xyz repo for 1 August 2016:
blabla-1.0-1-x86_gcc2.hpkg
blablabla-1.0-2-any.hpkg
OK, open for discussion. We have no actual way to enforce any of this, of course. But if we can determine what we want, then at least any new repo creator will know what the community expects.