8003ed8100
This resolves the confusion about the "url" field in repository definition files. However it changes the identifier of repositories. It seems to be a good idea to do this with a new release, as users will need to switch to new repos anyway and can accept special instructions at that time (we will include the instructions in the release notes). The new format uses a tag: uri as specified in https://tools.ietf.org/html/rfc4151 The rationale for this is: - We need a way to uniquely identify repositories - We want anyone to be able to create a repository easily, with no central registration, and in a way that does not results in accidental conflicts. We do not want to be running a registry to grant people an identifier for their repository. - Backwards compatibility with existing repositories and software should be preserved: some code and file formats in Haiku package tools expect or expected the identifier to be parsable as a BUrl. Existing 3rd-party repositories use an http or https URL as an identifier and may continue to do so (changing the identifier of existing repositories is not desirable) - Forwards compatibility if we want to change this again later - Optional: repository identifiers should be user readable. The tag: URI resolves this in the following way: - Backwards compatibility: it is still an URI, as the identifier previously was. - Forward compatibility: We can change to another URI scheme if we want to. In fact, each repository can decide what type of URI they want to use, "tag" is only a recommendation and put in use for the repos we provide. - Uniqueness + no centralization: the tag: URI specifies namespaces tied to a domain name (which is already needed to host a repository) and a date at which the domain is owned by the entity generating a tag. Inside that namespace, they can do as they wish. - User readability: the format is simple and text-based. Other possible alternatives are: - keeping the current solution of using http URLs. It has proven confusing because the repository hosting may be moved or mirrored while preserving the identifier. There is also work in progress to distribute packages using other protocols (eg. IPFS). - Using an uuid. This provides unique, decentralized identifiers, but is not user-readable. Backwards compatibility can be provided by wrapping the uuid into an "urn:uuid:" URI (see https://www.itu.int/en/ITU-T/asn1/Pages/UUID/uuids.aspx). - Using some other URI scheme such as "urn:oid:". I investigated some, but found none that provide a decentralized namespacing solution (except for "tag", of course). - Using a custom URI scheme of our own. This would normally require declaring it to the IANA (example: https://www.iana.org/assignments/uri-schemes/prov/apt for Debian packages) in order to not make the internet more of a mess than it already is. We would still need to define a way to generate URIs that protects people from getting accidental conflicts. The solution would probably be similar to what the "tag" URI scheme does, as there doesn't seem to be many other ways to guarantee uniqueness in (cyber)space and time without registration. - Not using an URI scheme: in addition to the problems of a custom URI scheme, this would break backwards compatibility (existing software would not accept the new format) and forwards compatibility (without a scheme in the identifier, it is hard to detect what it is supposed to be if we change formats later on) Change-Id: I970c23a546569994632c7bd570d11bdea95ba52e Reviewed-on: https://review.haiku-os.org/c/haiku/+/4106 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> |
||
|---|---|---|
| 3rdparty | ||
| build | ||
| data | ||
| docs | ||
| headers | ||
| src | ||
| .editorconfig | ||
| .gitignore | ||
| .gitreview | ||
| configure | ||
| Jamfile | ||
| Jamrules | ||
| lgtm.yml | ||
| License.md | ||
| ReadMe.Compiling.md | ||
| ReadMe.md | ||
Haiku
Homepage | Mailing Lists | IRC Channels | Issue Tracker | API docs
Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.
Goals
- Sensible defaults with minimal configuration required.
- Clean, clear, concise code.
- Unified desktop environment.
Trying Haiku
Haiku provides pre-built nightly images and release images. Haiku is compatible with a large variety of hardware, but in case you don't want to "take the plunge" and install Haiku on bare metal, you can install it on a virtual machine (VM) instead. If you've never used a VM before, you can follow one of the "Emulating Haiku" guides.
Compiling Haiku
See ReadMe.Compiling.
Contributing
Haiku is a meritocratic open source project with a large variety of tasks. Even if you can't write code, you can still help! Haiku needs designers, (technical) writers, translators, testers... Get involved and help out!
Contributing code
If you're submitting a patch to us, please make sure you're following the patch submitting guidelines.
If you're having trouble finding something in the source tree, you can use one of our web-based source code browsers:
- https://xref.landonf.org/ (OpenGrok, provided by Landon Fuller)
- https://git.haiku-os.org/ (git, provided by Haiku, Inc.)
Contributing documentation
The main piece of documentation that still needs work are the API docs (found
in the tree at docs/user). Just find an undocumented class, write
documentation for it, and submit a patch.
Contributing translations
See wiki:i18n.
Contributing software ports
See HaikuPorts.
Contributing to our infrastructure
See Infrastructure.