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

Use RHEL not CentOS Stream for EPEL 8 #40

Open
AdamWill opened this issue Sep 14, 2024 · 5 comments
Open

Use RHEL not CentOS Stream for EPEL 8 #40

AdamWill opened this issue Sep 14, 2024 · 5 comments

Comments

@AdamWill
Copy link
Contributor

The EPEL 8 config uses CentOS Stream:

    "epel8": {
      "profile_name": "centos-stream-8",
      "compose": "CentOS-Stream-8"
    },

But CentOS Stream 8 went EOL on May 31, and now the repos seem to be inaccessible (see https://src.fedoraproject.org/rpms/glfw/pull-request/6 ). @nirik says it should use RHEL 8 as a base instead.

mini-tps does have RHEL 8 profiles, so we could change profile_name to e.g. rhel-8.10.0. I don't know what compose should be, though. It would also need updating quite regularly as new RHEL 8 minor versions appear; I don't know if mini-tps could grow a rhel-8-latest symlink, or something.

@AdamWill
Copy link
Contributor Author

hum, possibly the mini-tps profiles won't work for Fedora CI, in which case we'd have an issue. maybe we can borrow the setup koji uses for EPEL builds? Kevin says "epel8 builds work by us syncing rhel8 and letting koji use that as an external repo. It's also not public."

@AdamWill
Copy link
Contributor Author

another thing I notice about this: it doesn't look like the EPEL pipelines do anything to make EPEL itself available in the test context? Which would mean tests will fail falsely for any EPEL build that depends on anything else from EPEL...

@carlwgeorge
Copy link

I brought this general problem up in OSCI-3778. I requested to have installability checks run on EPEL Bodhi updates. It was asked if this could be done on CentOS Stream, and I advised against it. Besides the lifecycle difference that is noted here, it also gives us false failures and false successes. The idea came up about getting RHEL machines in Testing Farm for Bodhi updates, but didn't seem to go anywhere. The issue was eventually closed without resolution.

We're in the process of standing up EPEL 10, and uninstallable packages are already showing up. We actually can use CentOS Stream 10 to test these updates right now, thanks to the new EPEL 10 structure. We'll still eventually need to have RHEL 10 for checks as well, and the need for RHEL 9 and RHEL 8 never went away.

My long-term goal is that a failed Bodhi installability check will block the update from going to stable, or at the very least disable the autopush based on time/karma.

cc: @msrb @thrix @jankaluza

@AdamWill
Copy link
Contributor Author

Note, installability is already known to have various issues which make it unsuitable for gating Fedora updates, without any EL-specific wrinkles. See at least https://pagure.io/fedora-ci/general/issue/448 .

@carlwgeorge
Copy link

Thanks for the reference to that other issue. I'm not aware of any packages in EPEL where certain combinations of subpackages from the same build are not installable together. Even if they do exist, they would be a tiny edge case. I would be quite happy with gated EPEL updates with an opt-opt mechanism for the edge cases.

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

No branches or pull requests

2 participants