Assign a distribution to yum

[ExplodingDragon]

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

[KN4CK3R]

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

[nephatrine]

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]

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.

[ExplodingDragon]

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.

[delvh]

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.

[KN4CK3R]

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.

[nephatrine]

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?

[ExplodingDragon]

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.

[nephatrine]

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.

[ExplodingDragon]

Any progress?

hybrid yum repository is simply not available for production environments.