Detection of Pkg Version is Flawed Around Repository + Architecture

[Andrew Lindesay]

Diagram

See this diagram and look for pkg_version to better understand the entities involved. Note that there is now a relationship stored from repository_source to architecture.)

As-Built

In general, it is necessary to be able to "address" a version of a package; a pkg_version. This is in the context of the following information;

• pkg.name
• semantic version (major, minor...)
• (architecture + repository) or repository_source

The concept of a repository in HDS is logical as in "HaikuPorts" then the concept of a repository_source is the supply of a repository for a given architecture. The naming might have been better; something for another time. An example might be;

• haikuports (is a repository)
  • haikuports_x86_gcc2 (is a repository_source)
  • haikuports_x86_64 (is a repository_source)

Problem

Historically it was assumed that the repository and architecture would effectively pin the repository_source when addressing for a package_version, but this is a false assumption because of the any architecture packages. The same package_version may be in two or more repository_source-s as any and because of this, it is ambiguous as to which to use. This ambiguity can lead to the wrong pkg_version being operated on and this, in turn, can lead to a number of quite complex problems.

Solution

The first step is to get the HD application to also send the code for the repository_source on APIs. This way, the client will be forward compatible with changes to the API in HDS to support working with the repository_source rather than the (repository + architecture).

After this, the HDS application needs to change as well so that the APIs address pkg_version-s with the code for the repository_source rather than the repository + architecture.

[Andrew Lindesay]

Completed.