-
Notifications
You must be signed in to change notification settings - Fork 236
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
Add CentOS Stream 10 + EPEL 10 configs #1424
Add CentOS Stream 10 + EPEL 10 configs #1424
Conversation
These work with Koji EPEL buildroot only for now since there are no composes, yet. Fixes: rpm-software-management#1421
|
||
[local] | ||
name=Extra Packages for Enterprise Linux $releasever - Koji Local - BUILDROOT ONLY! | ||
baseurl=https://kojipkgs.fedoraproject.org/repos/epel10.0-build/latest/$basearch/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note the 10.0
part of the link, while releasever=10 :-/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use $releasever_major${releasever_minor:+.$releasever_minor}
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really, we do dnf --installroot
sometimes; and the releasever
is poorly defined by "us" in Mock:
config_opts['releasever'] = '10' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way we could retrieve the latest koji epel 10 buildroot to populate that value? Because otherwise we'll have to update 10.y
into new numbers every few months.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm trying to tl;dr the original proposal https://discussion.fedoraproject.org/t/epel-10-proposal/44304/25 and it seems that at least the mirror/metalinks would (not ATM, since there are no composes yet) have a "floating" target eventually (the default).
Would we consider having something like epel10-latest -> epel10.0
symlink in Koji?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we want to ask fedpkg verrel
for every single mock
run (query API). It seems even easier/wiser/cost-effective to html-parse the koji repository URL (if dirlisting is available) or check for HTTP 200 vs 404. But still quite an inconvenient change in EL10 honestly. The koji-side symlink would be easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I wasn't clear, I wasn't suggesting running fedpkg verrel
from mock, just that for that command we'll need to solve a similar problem and the source of truth will be the koji epel10 build target. I'm not quite sure what you mean by a koji symlink.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both verrel
and Mock will need to get the info from Koji API. This is an equivalent problem to fedora-distro-aliases, and the #1328, or maybe #1295.
I'm not quite sure what you mean by a koji symlink
It would be nice if those were symlinks server-side:
https://kojipkgs.fedoraproject.org/repos/epel10.0-build/
https://kojipkgs.fedoraproject.org/repos/epel10-latest-build/
... and if the epel10-latest-build
symlink was updated anytime we start building for a new minor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is how https://kojipkgs.fedoraproject.org/repos/rawhide/latest/ works. The relengs update it from f41-build to 42-build on branching. See e.g. https://pagure.io/releng/issue/12255
So indeed, we would probably want epel10-c10s and epel10-rhel10 links to latest and second to latest eventually
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
second to latest?
Actually, is anyone against merging this as-is? It's not an optimal long-term solution, but it should work well for now, even in Fedora Copr. |
Since nobody votes against merging this, and neither TF complaints:
... I will merge it so we have it in the next release. |
So, we could do links, although I would prefer to avoid it as much as possible as it means more 'manual' steps. Also, just to note, as soon as we have real epel10 repos we should default to pointing to those, not the buildroot. IMHO, the buildroot should be like the 'local' repo for fedora, disabled by default, but possible for developers who need it for some specific region. I always worry about more and more people hitting kojipkgs for these things instead of using the mirror network. ;) |
That's the truth and the unfortunate cons of the change, but I'm afraid that if we don't do this manual step once in the source, every consumer (like mock-core-configs) needs to do the manual steps instead. Which seems even worse.
Absolutely! As I understood it, there will be such a floating target in composes, too (no need to update mock-core-configs for minor RHEL bumps every 6 months). |
These work with Koji EPEL buildroot only for now since there are no composes, yet.
Fixes: #1421