Support packages with different architectures #62

New Issue

Jef Roosens · 2022-02-02T10:55:42Z

Jef Roosens commented

2022-02-02 10:55:42 +00:00

Currently the server does not check what architecture a package is, or whether it's already present in the repository with a different architecture. I think we call solve this problem in the following way:

Instead of having one repository, we could have one for each architecture. When a package is published, we inspect the architecture & add it to the correct repository. If a package has the "any" architecture, we add it to all repos.

Using an environment variable (that defaults to x86_64), we can route requests to the proper repository. If no architecture subpath is used, we route to the default one. Otherwise, e.g. if the user requests /arm64/vieter.db, we return the correct one.

This could also be expanded once we have multi-repository support, where each repository has its own sub-repositories for each architecture. /some-repo.db would return the default architecture for that repo, while /amd64/some-repo.db would return the correct one for that architecture.

Currently the server does not check what architecture a package is, or whether it's already present in the repository with a different architecture. I think we call solve this problem in the following way: Instead of having one repository, we could have one for each architecture. When a package is published, we inspect the architecture & add it to the correct repository. If a package has the "any" architecture, we add it to all repos. Using an environment variable (that defaults to x86_64), we can route requests to the proper repository. If no architecture subpath is used, we route to the default one. Otherwise, e.g. if the user requests `/arm64/vieter.db`, we return the correct one. This could also be expanded once we have multi-repository support, where each repository has its own sub-repositories for each architecture. `/some-repo.db` would return the default architecture for that repo, while `/amd64/some-repo.db` would return the correct one for that architecture.

Jef Roosens added this to the 0.2.0 milestone 2022-02-02 10:55:42 +00:00

Jef Roosens added the

enhancement

label 2022-02-02 10:55:42 +00:00

Jef Roosens added a new dependency 2022-02-13 19:06:48 +00:00

#70 Deadlock when locking map in MultiArchRepo

Jef Roosens removed this from the 0.2.0 milestone 2022-02-14 14:14:53 +00:00

Jef Roosens added this to the 0.2.0 milestone 2022-03-27 13:06:16 +00:00

Jef Roosens removed a dependency 2022-03-27 13:06:59 +00:00

#70 Deadlock when locking map in MultiArchRepo

Jef Roosens referenced this issue

2022-03-29 11:53:46 +00:00