Assign a distribution to yum #11039

New Issue

GiteaMirror · 2025-11-02T09:25:48-06:00

GiteaMirror commented

2025-11-02 09:25:48 -06:00

Originally created by @ExplodingDragon on GitHub (Jun 16, 2023).

Feature Description

Sometimes we need to compile RPM packages for multiple distributions (el7, el9, f34 ...) All packages are put together and sometimes a package does not work on a particular distribution, which may lead to incorrect installation of a package not compiled for that distribution.

After uploading:

Screenshots

Originally created by @ExplodingDragon on GitHub (Jun 16, 2023). ### Feature Description Sometimes we need to compile RPM packages for multiple distributions ` (el7, el9, f34 ...)` All packages are put together and sometimes a package does not work on a particular distribution, which may lead to incorrect installation of a package not compiled for that distribution. ![图片](https://github.com/go-gitea/gitea/assets/33776693/feac8cfd-6336-4890-ae0a-f3581774db2a) ![图片](https://github.com/go-gitea/gitea/assets/33776693/d746b823-691f-4484-937a-e84ce74d8145) ![图片](https://github.com/go-gitea/gitea/assets/33776693/30acfa9b-db25-48e0-b6cf-e963a90cdda8) After uploading: ![图片](https://github.com/go-gitea/gitea/assets/33776693/aee14077-77fc-4ed5-9017-95a4ab2c7930) ### Screenshots

GiteaMirror added the topic/packages type/proposal type/feature labels 2025-11-02 09:25:48 -06:00

GiteaMirror closed this issue

2025-11-02 09:25:48 -06:00

GiteaMirror commented

2025-11-02 09:25:49 -06:00

@KN4CK3R commented on GitHub (Jun 16, 2023):

How does YUM/DNF decide which file to download? Debian for example uses a different configuration for such parameters.

@KN4CK3R commented on GitHub (Jun 16, 2023): How does YUM/DNF decide which file to download? Debian for example uses a [different configuration](https://docs.gitea.com/1.20/usage/packages/debian#configuring-the-package-registry) for such parameters.

GiteaMirror commented

2025-11-02 09:25:49 -06:00

@nephatrine commented on GitHub (Jun 16, 2023):

Normally a repository would have different paths for different versions (el7, el8, etc.) and in the yum/dnf config you'd use the $releasever in the baseurl to select the right repo for you. For instance within https://download.docker.com/linux/centos/ you can see they have a separate directory for each release version. Each combination of release version and architecture is essentially its own standalone repository but you can just use one repo file with a line like this to address the correct one for your system:

baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable

That stable on the end is similar to the {component} configuration shown in the debian config you linked and it would be nice to support having multiple RPM package sets in a similar way to what gitea is already apparently doing for Debian.

@nephatrine commented on GitHub (Jun 16, 2023): Normally a repository would have different paths for different versions (el7, el8, etc.) and in the yum/dnf config you'd use the $releasever in the baseurl to select the right repo for you. For instance within https://download.docker.com/linux/centos/ you can see they have a separate directory for each release version. Each combination of release version and architecture is essentially its own standalone repository but you can just use one repo file with a line like this to address the correct one for your system: `baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable` That `stable` on the end is similar to the `{component}` configuration shown in the debian config you linked and it would be nice to support having multiple RPM package sets in a similar way to what gitea is already apparently doing for Debian.

GiteaMirror commented

2025-11-02 09:25:49 -06:00

@nephatrine commented on GitHub (Jun 17, 2023):

I did some testing on my own using AlmaLinux 9 and dnf was smart enough to pick the right architecture binaries even if those are all mixed together in one repo - but it is very confused if you have packages for different distro versions in one repo. I think you just need to be able to provide a {distribution} and perhaps {component} in the same way as Debian and publish packages using a path like this:

https://gitea.example.com/api/packages/{owner}/rpm/{distribution}/{component}/upload

The .repo file downloaded could then would just have $releasever where {distribution} is like https://gitea.example.com/api/packages/{owner}/rpm/$releasever/{component}. Each of those URLs would have to be presented as its own repository root. I suppose each {component} would need its own .repo file as well or they'd all have to be listed as separate repositories in one master .repo file. It's not like debian where you can just list a bunch of "tags" after the url for various components unfortunately. I'm not sure how you'd want to handle that.

I'm also not sure how you'd handle packages users have already uploaded in 1.20.0 using the current way it works so you would probably need to continue supporting distributionless componentless packages to not break those.

@nephatrine commented on GitHub (Jun 17, 2023): I did some testing on my own using AlmaLinux 9 and dnf was smart enough to pick the right architecture binaries even if those are all mixed together in one repo - but it is very confused if you have packages for different distro versions in one repo. I think you just need to be able to provide a {distribution} and perhaps {component} in the same way as Debian and publish packages using a path like this: `https://gitea.example.com/api/packages/{owner}/rpm/{distribution}/{component}/upload` The `.repo` file downloaded could then would just have $releasever where {distribution} is like `https://gitea.example.com/api/packages/{owner}/rpm/$releasever/{component}`. Each of those URLs would have to be presented as its own repository root. I suppose each {component} would need its own .repo file as well or they'd all have to be listed as separate repositories in one master .repo file. It's not like debian where you can just list a bunch of "tags" after the url for various components unfortunately. I'm not sure how you'd want to handle that. I'm also not sure how you'd handle packages users have already uploaded in 1.20.0 using the current way it works so you would probably need to continue supporting distributionless componentless packages to not break those.

GiteaMirror commented

2025-11-02 09:25:49 -06:00

@ExplodingDragon commented on GitHub (Jun 18, 2023):

1.20.0 was not released stable, and including incompatible changes might not have much impact.
Or include an index of all RPM packages under the organization at the old address.

@ExplodingDragon commented on GitHub (Jun 18, 2023): 1.20.0 was not released stable, and including incompatible changes might not have much impact. Or include an index of all RPM packages under the organization at the old address.

GiteaMirror commented

2025-11-02 09:25:49 -06:00

@delvh commented on GitHub (Jun 18, 2023):

1.20.0 was not released stable

Yes, but we are already in feature freeze for 1.20.
This means that we won't add new features (or breaking changes) for it anymore.

@delvh commented on GitHub (Jun 18, 2023): > 1.20.0 was not released stable Yes, but we are already in feature freeze for 1.20. This means that we won't add new features (or breaking changes) for it anymore.

GiteaMirror commented

2025-11-02 09:25:50 -06:00

@KN4CK3R commented on GitHub (Jun 19, 2023):

I looked into the RPM tags and it looks like there is no way (?) to read the distribution from a RPM file. There are RPMTAG_DISTTAG and RPMTAG_DISTRIBUTION but both were always empty in my tests. So the distribution must be specified when uploading a package. I don't currently know if we want to support a component level. Some use them, others don't. If we decide to support it, we basicaly force everyone to use it because otherwise the api routing gets painful. Since the users are free to choose whatever they like as distribution and architecture we can't provide helper variables like $releasever and $basearch in the repo file because they may never match. A repo file with different "endpoints" looks nice but may therefore not usable and we would have to provide multiple repo files for every combination.

If we decide to change the current "flat" logic I would just make it a breaking change. Reuploading existing packages with the correct distribution should not be as hard as supporting a "legacy" api.

@KN4CK3R commented on GitHub (Jun 19, 2023): I looked into the RPM tags and it looks like there is no way (?) to read the distribution from a RPM file. There are `RPMTAG_DISTTAG` and `RPMTAG_DISTRIBUTION` but both were always empty in my tests. So the `distribution` must be specified when uploading a package. I don't currently know if we want to support a `component` level. [Some](https://download.docker.com/linux/centos/8/aarch64/) use them, [others](https://nginx.org/packages/mainline/centos/8/aarch64/) don't. If we decide to support it, we basicaly force everyone to use it because otherwise the api routing gets painful. Since the users are free to choose whatever they like as `distribution` and `architecture` we can't provide helper variables like `$releasever` and `$basearch` in the repo file because they may never match. A [repo file](https://download.docker.com/linux/centos/docker-ce.repo) with different "endpoints" looks nice but may therefore not usable and we would have to provide multiple repo files for every combination. If we decide to change the current "flat" logic I would just make it a breaking change. Reuploading existing packages with the correct `distribution` should not be as hard as supporting a "legacy" api.

GiteaMirror commented

2025-11-02 09:25:50 -06:00

@nephatrine commented on GitHub (Jun 20, 2023):

I'm certainly not arguing we need "components" and agree that we can skip them if need be, I only mentioned them for the sake of debian parity. A way to specify distribution is the critical necessity. While every RPM repo I've seen in the wild does split it out by architecture as well, I'm not sure there is a genuine technical need for that since that information is stored in the RPM... but I've only done limited testing so there may be some instance where it is useful or even necessary.

This might be a stretch, but would it be possible to allow the user-provided "distribution" to include "/"? Then a user could specify the arch or even component with just that one token so you could have just "8" or "8/aarch64" or "8/aarch64/edge" etc. depending on the needs of the project? Or would that be too complex or open to abuse?

@nephatrine commented on GitHub (Jun 20, 2023): I'm certainly not arguing we need "components" and agree that we can skip them if need be, I only mentioned them for the sake of debian parity. A way to specify distribution is the critical necessity. While every RPM repo I've seen in the wild does split it out by architecture as well, I'm not sure there is a genuine technical need for that since that information **is** stored in the RPM... but I've only done limited testing so there may be some instance where it is useful or even necessary. This might be a stretch, but would it be possible to allow the user-provided "distribution" to include "/"? Then a user could specify the arch or even component with just that one token so you could have just "8" or "8/aarch64" or "8/aarch64/edge" etc. depending on the needs of the project? Or would that be too complex or open to abuse?

GiteaMirror commented

2025-11-02 09:25:50 -06:00

@ExplodingDragon commented on GitHub (Jun 22, 2023):

but would it be possible to allow the user-provided "distribution" to include "/"? Then a user could specify the arch or even component with just that one token so you could have just "8" or "8/aarch64" or "8/aarch64/edge" etc.

There is no need to be so complicated, YUM/DNF can recognize packages of different architectures under mixed repositories, even src.rpm .

Similar to

dnf config-manager --add-repo https://gitea.example.com/api/packages/{owner}/rpm/{distribution}.repo

to make the distinction.

EDIT: The distribution here is provided by the user, e.g. centos-core, rocky-9-nonfree, and does not represent the final Linux distribution.

@ExplodingDragon commented on GitHub (Jun 22, 2023): > but would it be possible to allow the user-provided "distribution" to include "/"? Then a user could specify the arch or even component with just that one token so you could have just "8" or "8/aarch64" or "8/aarch64/edge" etc. There is no need to be so complicated, YUM/DNF can recognize packages of different architectures under mixed repositories, even src.rpm . Similar to ``` dnf config-manager --add-repo https://gitea.example.com/api/packages/{owner}/rpm/{distribution}.repo ``` to make the distinction. **EDIT**: The `distribution` here is provided by the user, e.g. `centos-core`, `rocky-9-nonfree`, and does not represent the final Linux distribution.

GiteaMirror commented

2025-11-02 09:25:50 -06:00

@nephatrine commented on GitHub (Jun 22, 2023):

Yeah I suppose if the distribution is just arbitrary and not supposed to be a releasever, then that absolutely works. Does gitea handle src rpms? I must say I didn't even try that yet.

@nephatrine commented on GitHub (Jun 22, 2023): Yeah I suppose if the distribution is just arbitrary and not supposed to be a releasever, then that absolutely works. Does gitea handle src rpms? I must say I didn't even try that yet.

GiteaMirror commented

2025-11-02 09:25:50 -06:00

@ExplodingDragon commented on GitHub (Jul 5, 2023):

Any progress?

hybrid yum repository is simply not available for production environments.

@ExplodingDragon commented on GitHub (Jul 5, 2023): Any progress? hybrid yum repository is simply not available for production environments.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#11039