mock-core-configs: maintenance of EPEL 10 minor versions #1427
Comments
|
I think we have two possible options we can take for EPEL 10 mock configs. Which option we choose affects how the koji local baseurl problem would be handled. option 1We fully embrace minor versions for EPEL and RHEL in mock-core-configs. This could look something like this: With this setup, every six months we would need to create new rhel and rhel+epel minor version configs. The koji local baseurl in epel-10-branched.tpl can use Users who need to build for EPEL minor version branches (e.g. epel10.0 instead of epel10) would also have to create a new option 2We partially ignore RHEL and EPEL minor versions in mock-core-configs. We intend to primarily target two minor versions at a time, somewhat like we do now with rhel+epel and centos-stream+epel-next. This could look something like this: This setup avoids the sprawl of minor version config files and symlink. Sharing an epel-10.tpl file for both CentOS and RHEL would mean that we would be forced to use the koji symlink approach. We would definitely need to include this symlink management into the EPEL branching SOP. Users who need to build for EPEL minor version branches will still need to create a new |
|
I'm sorry for not getting back to this sooner. This is more complicated than I thought before :-) because we are adding two more floating targets that need regular bumps, not just one. Now I think I understood the EPEL 10 proposal: Minor versions are still built against RHEL + EPEL (nah, not easy to replicate in non-Koji environment, i.e., local mock), and the "future/development minor" (intentionally not using the word "next") will be built against (public && nice) CentOS Stream + EPEL. Until now I was frozen in the old-school EPEL policy with only one EPEL minor... Ad option 1:
I'm afraid this is not possible in Mock; or? The DNF (e.g.) on Fedora 40 host doesn't know the variable value before finishing Also, I don't think we need to introduce RHEL minor configs, do you think it brings any real value? The thing is that mock-core-configs users have no access to pre-release RHEL packages, and very rarely (if at all) need Ad option 2: option 3 Simply put we care about these EPEL 10 variants: Then, the MINOR "bump event" is not going to happen at the same time in "koji" and "mirrors". The stable "koji" repo is going to be branched first, and probably later composes will appear, and start getting mirrored. This is similar to Rawhide branching, and then - one may argue that in mock-core-configs we'll probably want to make the switch once the bumped composes are available and mirrored. The major problem is that we have been doing this dance ~2 a year already for Rawhide, and now we'll have to do this ~2x more because EPEL. We have the symlinks for rawhide (good) but we have to keep more versions in parallel (EPEL is just two latest). Now, I hear that at the time of branching new 10.2 from 10.1, 10.1 becomes "stable branched", but "previous stable" 10.0 becomes obsoleted and archived on mirrors. This means that the "current mock's" So to me it is hard to imagine all of this happening without Koji symlinks, but also without the MirrorManager symlinks - and I mean for both the branched and development variants! With
... with those, we can have Mock configs for epel and epel-branched provided once, and keep using them without periodic bumps. |
This is what we have the container bootstrap feature for, right?
I do think it brings value. I've had to create my own custom RHEL minor configs in the past when troubleshooting build failures. It was usually trying to answer the question "does this fail to build on the previous minor version too, or is there something in the new minor version at fault". The RHEL CDN has minor versions directories (for all releases, not just EUS), and the current RHEL templates work with this just by setting
I think we're on the right path with this part. As for the rest of option 3, how would you feel about removing the word "branched" from the configs (but not the template)? So However my bigger concern with option 3 is I don't know how we're going to have fedpkg map the minor version dist-git branches to the mock configs in this setup. This isn't something a koji repo symlink would solve. I guess we could just rely on users to create their own symlinks, not only for the preferred base distro (RHEL, Alma, etc.) but for the minor version as well. Perhaps most EPEL maintainers will just focus on the leading minor version to avoid this hassle, which would work out reasonably well in the new model. It's expected that some EPEL packages will be available for CentOS users first, and deferred until the next minor version for RHEL users (a bit like most RHEL updates).
I don't think it would stop working. Archived EPEL content works like Fedora. The content gets archived, mirrormanager detects it and starts returning the archive mirror links for the same requests it previously returned regular mirror links for.
Early on in the proposal we talked about having symlinks in the published repo tree (
I can create the symlink for the latest minor and put a step in our SOP for updating it, but I'd like to hold off on the second symlink to see if we can get things working with So, based on all of this, I think our initial setup can look like this: And then when RHEL 10 is released, we add these: And just make sure we have an appropriate message about both choosing your base distro and your minor version via symlink if you try to build for a non-existent config such as How does that sound as the plan of record? I'm happy to implement these stages as they become feasible. |
Yes but not always. Not always possible to use podman container for initializing the bootstrap chroot, and the bootstrap chroot - if already initialized - provides new/good enough DNF version so we had no need so far to re-initialize it. Practically it means that if user caches bootstrap chroot with releasever_minor 0, it will always install target chroot 10.0 even though we should be building against 10.1. This would be precedent (no chroot so far requires bootstrap image feature). And we haven't got a solution for #1289. |
github-project-automation
bot
moved this from In 3 months
to Needs triage
in CPT Kanban
|
I submitted/closed the issue by mistake. I'm sorry. Continuing:
Agreed, seems useful sometimes - but this deserves a separate PR anyway. I think that we could provide some macro magic for these use-cases, if there's an actual demand. Something like this, but named
Sounds good! Eventually, we can keep just one epel-10.tpl if there's a reasonable if-else logic, it is hard to predict now.
See the "mock bootstrap cache problem" above; this is going to work but not always. I think it is much safer to hard-code the releasever_minor number in mock configuration, and make the maintenance harder :-(
Is this something where fedora-distro-aliases would help? We can solve this separately.
Sounds good. Is it worth documenting these nuances somewhere? e.g. here?
👍
👍 The RHEL+EPEL config is indeed a matter of the (near, post GA) future.
I'm not confident about the releasever_minor thing, at least if not hard-coded. But otherwise sounds good!
Yes! Thank you. |
Previously the EPEL 10 config only included the koji local repo, because that was the only thing available at the time. We now have working MirrorManager metalinks that we can use for the proper repos. Now that we have those repos, we can set the koji local repo to disabled by default, matching earlier EPEL configs. We also now have a koji symlink that will be updated over time to point to the latest minor version tag buildroot repo, which can be used in the koji local baseurl. This avoids the inconvenience of updating that baseurl manually every six months. Resolves: rpm-software-management#1427
Previously the EPEL 10 config only included the koji local repo, because that was the only thing available at the time. We now have working MirrorManager metalinks that we can use for the proper repos. Now that we have those repos, we can set the koji local repo to disabled by default, matching earlier EPEL configs. We also now have a koji symlink that will be updated over time to point to the latest minor version tag buildroot repo, which can be used in the koji local baseurl. This avoids the inconvenience of updating that baseurl manually every six months. Fixes: rpm-software-management#1427
praiskup
changed the title
praiskup
changed the title
|
@carlwgeorge I updated the title of this issue so it better matches my original intentions, this was not meant to just deal with the I also opened fedora-copr/copr#3469 to properly discuss related Copr problems (your comments are very welcome). |
Previously the EPEL 10 config only included the koji local repo, because that was the only thing available at the time. We now have working MirrorManager metalinks that we can use for the proper repos. Now that we have those repos, we can set the koji local repo to disabled by default, matching earlier EPEL configs. We also now have a koji symlink that will be updated over time to point to the latest minor version tag buildroot repo, which can be used in the koji local baseurl. This avoids the inconvenience of updating that baseurl manually every six months. Relates: rpm-software-management#1427
Previously the EPEL 10 config only included the koji local repo, because that was the only thing available at the time. We now have working MirrorManager metalinks that we can use for the proper repos. Now that we have those repos, we can set the koji local repo to disabled by default, matching earlier EPEL configs. We also now have a koji symlink that will be updated over time to point to the latest minor version tag buildroot repo, which can be used in the koji local baseurl. This avoids the inconvenience of updating that baseurl manually every six months. Relates: rpm-software-management#1427
Previously the EPEL 10 config only included the koji local repo, because that was the only thing available at the time. We now have working MirrorManager metalinks that we can use for the proper repos. Now that we have those repos, we can set the koji local repo to disabled by default, matching earlier EPEL configs. We also now have a koji symlink that will be updated over time to point to the latest minor version tag buildroot repo, which can be used in the koji local baseurl. This avoids the inconvenience of updating that baseurl manually every six months. Relates: #1427
github-project-automation
bot
moved this from In 3 months
to Needs triage
in CPT Kanban
The problem was discussed in #1424, the
[local]Koji repository contains10.0string, and we'll need to move it to10.1at some point (maintenance hell). We should avoid this inconvenience.Important reading first:
The text was updated successfully, but these errors were encountered: