-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assign a distribution to yum #25304
Comments
How does YUM/DNF decide which file to download? Debian for example uses a different configuration for such parameters. |
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:
That |
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:
The 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. |
1.20.0 was not released stable, and including incompatible changes might not have much impact. |
Yes, but we are already in feature freeze for 1.20. |
I looked into the RPM tags and it looks like there is no way (?) to read the distribution from a RPM file. There are If we decide to change the current "flat" logic I would just make it a breaking change. Reuploading existing packages with the correct |
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? |
There is no need to be so complicated, YUM/DNF can recognize packages of different architectures under mixed repositories, even src.rpm . Similar to
to make the distinction. EDIT: The |
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. |
Any progress? hybrid yum repository is simply not available for production environments. |
The current rpm repository places all packages in the same repository, and different systems (el7,f34) may hit packages that do not belong to this distribution ( #25304 ) , which now supports grouping of rpm.  Fixes #25304 . Fixes #27056 . Refactor: [#25866](#25866)
The current rpm repository places all packages in the same repository, and different systems (el7,f34) may hit packages that do not belong to this distribution ( go-gitea#25304 ) , which now supports grouping of rpm.  Fixes go-gitea#25304 . Fixes go-gitea#27056 . Refactor: [go-gitea#25866](go-gitea#25866)
The current rpm repository places all packages in the same repository, and different systems (el7,f34) may hit packages that do not belong to this distribution ( go-gitea#25304 ) , which now supports grouping of rpm.  Fixes go-gitea#25304 . Fixes go-gitea#27056 . Refactor: [go-gitea#25866](go-gitea#25866)
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
The text was updated successfully, but these errors were encountered: