Better package management #1

New Issue

Jef Roosens · 2023-08-02T14:58:30+02:00

Jef Roosens commented

2023-08-02 14:58:30 +02:00

The concept of "arch-repos" isn't really needed. A repo can simply be a collection of packages of various architectures, with each architecture-specific route only serving the packages for that architecture
"any" packages should be served for any architecture, not just for those currently present. DB files could simply be generated on the fly when needed.
File storage for repositories could be flattened, as different architectures will not collide anyways. This would also remove the need to store "any" packages multiple times using hard links
Repositories should be able to have arbitrarily nested paths, so both archlinux/core and endeavouros are valid routes for repositories. We would just need to prevent nested repositories, or we could allow nested repositories but only allow packages in the lowest levels.

* The concept of "arch-repos" isn't really needed. A repo can simply be a collection of packages of various architectures, with each architecture-specific route only serving the packages for that architecture * "any" packages should be served for *any* architecture, not just for those currently present. DB files could simply be generated on the fly when needed. * File storage for repositories could be flattened, as different architectures will not collide anyways. This would also remove the need to store "any" packages multiple times using hard links * Repositories should be able to have arbitrarily nested paths, so both `archlinux/core` and `endeavouros` are valid routes for repositories. We would just need to prevent nested repositories, or we could allow nested repositories but only allow packages in the lowest levels.

Jef Roosens commented

2023-08-02 15:03:53 +02:00

Poster

In the repositories directory, we could still store the desc & files files in their own directory sorted by repo and architecture, but the "any" packages could just be kept separate as their own distinct architecture as well, with these files being added to every architecture's database archives instead of copying them to every architecture.

If a new architecture is requested, that architecture's database archives could be generated on the fly if needed. This would however open up the possibility to spam the server with new architectures, so this mechanism should be considered carefully.

In the repositories directory, we could still store the `desc` & `files` files in their own directory sorted by repo and architecture, but the "any" packages could just be kept separate as their own distinct architecture as well, with these files being added to every architecture's database archives instead of copying them to every architecture. If a new architecture is requested, that architecture's database archives could be generated on the fly if needed. This would however open up the possibility to spam the server with new architectures, so this mechanism should be considered carefully.

Jef Roosens commented

2023-08-02 15:23:24 +02:00

Poster

The technique for nested repositories could also pave the way for repository mirroring, as all repositories for a distro could be combined under the same meta-repository.

Jef Roosens commented

2023-08-07 11:20:39 +02:00

Poster

We could introduce the concept of an "external repository" where we could add a list of repositories that a Rieter repository is expected to be used along with, e.g. we add the list of Arch repositories so that the system can know that this repository can't stand on its own (groups can contain package from these other repos, dependencies can come from here).

Jef Roosens closed this issue

2024-07-01 21:05:00 +02:00

Sign in to join this conversation.