Do not enable epel on EL 10

[spetrosi]

prepare:, how: feature, epel: enabled fails on EL 10. prepare's feature does not provide a way to avoid running on a specific platform. Hence, my prepare passes on all platforms but fails on EL 10 because EL 10 doesn't have epel-release available:

fatal: [[email protected]]: FAILED! => {"changed": false, "failures":
["No package epel-release available."], "msg": "Failed to install some
of the specified packages", "rc": 1, "results": []}

For now, avoid enabling epel on EL 10.

Pull Request Checklist

• [ ] implement the feature
• [ ] write the documentation
• [ ] extend the test coverage
• [ ] update the specification
• [ ] adjust plugin docstring
• [ ] modify the json schema
• [ ] mention the version
• [ ] include a release note

[spetrosi]

On other platforms, I enable epel to install beakerlib. On EL 10, beakerlib is installed by default from beaker-harness.

[happz]

On other platforms, I enable epel to install beakerlib. On EL 10, beakerlib is installed by default from beaker-harness.

That is true, but that applies only to RH-internal testing, correct? Nobody outside of RH will have access to any beaker-harness repo. BTW, wouldn't beaker-harness provide beakerlib package for RHEL9 and RHEL8 as well?

[spetrosi]

I would dare to say that there will be EPEL10, its nonexistence is just temporary

This is a valid concerns, and it means that if we apply this patch we need to remove it after epel i available on EL 10.

BTW, wouldn't beaker-harness provide beakerlib package for RHEL9 and RHEL8 as well?

It does provide the package, but it doesn't install it, and doesn't do the logic to enable epel, but I can workardound this.

That said, I've applied such a preparation task in my plan instead of using feature: epel` and it works fine. I agree to close this PR.

  - name: Enable epel to install beakerlib
    script: |
      # CS 10 and Fedora doesn't require epel
      if grep -q -e 'CentOS Stream release 10' -e 'Fedora release' /etc/redhat-release; then
        exit 0
      fi
      yum install epel-release yum-utils -y
      yum-config-manager --enable epel epel-debuginfo epel-source 

[happz]

I would dare to say that there will be EPEL10, its nonexistence is just temporary

This is a valid concerns, and it means that if we apply this patch we need to remove it after epel i available on EL 10.

Yes, that would indeed happen. And I wouldn't be afraid of it, EPEL is simply not yet available for RHEL-10, no point in installing it now, but one day, we will need to support it, so, not much we can do about such a switcheroo :)

[happz]

@spetrosi why closing this PR? :O The idea was correct, AFAICT, EPEL 10 is not available, therefore tmt should not attempt to install it. The revert will be needed in the future, but that's how things are, and it's a big deal.

[spetrosi]

Okay, I've added comments inline as you suggested.

[spetrosi]

@happz is it ready to be merged?

[happz]

@happz is it ready to be merged?

I don't think so, it needs more reviewers :) And ready or not, it needs some labels and a milestone.

[happz]

/packit build

[happz]

Unrelated failures - plenty of them. Merging.

[spetrosi]

Thank you for reviews and merging, when do you expect this to be available in production?

[happz]

Thank you for reviews and merging, when do you expect this to be available in production?

Released? Early September, 1.36 is supposed to be completed at the end of August. In TF? A week or two after that.