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.
andponlin
commented
2 years ago
Diagram
See this diagram and look for
pkg_versionto better understand the entities involved. Note that there is now a relationship stored fromrepository_sourcetoarchitecture.)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.namemajor,minor...)architecture+repository) orrepository_sourceThe concept of a
repositoryin HDS is logical as in "HaikuPorts" then the concept of arepository_sourceis the supply of arepositoryfor a givenarchitecture. The naming might have been better; something for another time. An example might be;haikuports(is arepository)haikuports_x86_gcc2 (is arepository_source)haikuports_x86_64 (is arepository_source)Problem
Historically it was assumed that the
repositoryandarchitecturewould effectively pin therepository_sourcewhen addressing for apackage_version, but this is a false assumption because of theanyarchitecture packages. The samepackage_versionmay be in two or morerepository_source-s asanyand because of this, it is ambiguous as to which to use. This ambiguity can lead to the wrongpkg_versionbeing 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_sourceon APIs. This way, the client will be forward compatible with changes to the API in HDS to support working with therepository_sourcerather 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 therepository_sourcerather than therepository+architecture.