| 76 | | The details of how changes are made to a repository (when packages shall be added, replaced, or removed) have not been decided on yet. Most likely the server side will be kept very simple by having the preparation been done on the client side. That means the client would compute the new repository index file, upload all new files including the index file, and finally tell the server to switch to the new index. |
| | 76 | === Standard Repositories === |
| | 77 | |
| | 78 | There are two standard repositories for Haiku: |
| | 79 | * the Haiku repository, which only contains the small set of packages that is built by Haiku's build system (haiku.hpkg, haiku_devel.hpkg, etc.) and |
| | 80 | * the HaikuPorts repository, which contains the packages maintained by HaikuPorts. |
| | 81 | |
| | 82 | For the different builds and releases there are different instances of those two repositories: |
| | 83 | * There are snapshot repository instances for any repository version that was ever available (to save space old versions may be removed/thinned out). Those repositories will never be updated. Their main purpose is to be able to retrospectively get a certain Haiku version for testing and comparisons. |
| | 84 | * For each official major release there will be an instance of the two repositories. For small updates the repositories will simply be updated. An official Haiku release is pre-configured with the corresponding repositories, so that the user can conveniently keep their Haiku up-to-date. The update to the next major release has to be requested explicitly. |
| | 85 | * Similar to the nightly images there are repository instances that are continuously updated to the latest head of development. Those are suitable mainly for testers and developers. |
| | 86 | * For each state of the HaikuPorts repository a Haiku development revision refers to a snapshot version of the repository is created. This allows to check out and build older Haiku revisions with their corresponding HaikuPorts packages. |
| | 87 | |
| | 88 | The repositories are maintained via files in the Haiku git repository. For each architecture and each repository the Haiku git repository contains a file listing the packages for that repository. For the HaikuPorts repositories the packages are listed with the respective version. For the Haiku repositories the version is implied. |
| | 89 | |
| | 90 | Whenever a developer wants to update or add a HaikuPorts package, the new package file has to be uploaded to their vmrepo.haiku-os.org account and the package list file for the repository has to be adjusted accordingly. A helper script is provided to perform both steps. Afterward the change needs to be committed and pushed to vmrepo.haiku-os.org. The push hook on the server analyzes the change, moves the new package file from the developer's account to the repository directory, and builds a new repository snapshot. If the package file is missing or broken, the push is rejected with a message notifying the developer about the problem. |
| | 91 | |
| | 92 | The creation and update of repositories for official releases has to be triggered explicitly on the server. In either case the Haiku repository is built by the build service. |
