Skip to content
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

Merged
merged 1 commit into from
Aug 15, 2024

Conversation

praiskup
Copy link
Member

These work with Koji EPEL buildroot only for now since there are no composes, yet.

Fixes: #1421

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/
Copy link
Member Author

@praiskup praiskup Aug 14, 2024

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 :-/

Copy link
Contributor

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}?

Copy link
Member Author

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'

Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

second to latest?

@praiskup
Copy link
Member Author

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.

@praiskup
Copy link
Member Author

Since nobody votes against merging this, and neither TF complaints:

PASSED: centos-stream+epel-10-x86_64.cfg (tmpfs)
PASSED: centos-stream+epel-10-x86_64.cfg

... I will merge it so we have it in the next release.

@praiskup praiskup merged commit 3802ca3 into rpm-software-management:main Aug 15, 2024
22 checks passed
@nirik
Copy link

nirik commented Aug 16, 2024

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. ;)

@praiskup
Copy link
Member Author

So, we could do links, although I would prefer to avoid it as much as possible as it means more 'manual' steps.

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.

IMHO, the buildroot should be like the 'local' repo for fedora, disabled by default

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

EPEL 10 chroots
5 participants