Download both epel and epel-next release packages on centos targets

[dherrerace]

Yesterday someone raised a problem with the installability-CI on the EPEL Matrix channel, where their PRs wouldn't be able to pass.

https://artifacts.dev.testing-farm.io/f785c048-458b-4fd1-a37b-39894af18ce5/

Looking into this, I noticed that the current preparation scripts install the epel release package from the release url, but as it requires the epel-next package, it's version conflicts with the one already distributed with the image.

I added a fix for the EPEL9 case, since it's the only active version that uses the epel-next repo. EPEL8 was retired because of Centos8 EOL and EPEL10 uses a different model without the epel-next repo.

[LecrisUT]

Iirc the issue you had was that epel9-next was pre-installed? I think what you need here is to make sure epel9-next is uninstalled before running the section there because you want to pick up only on epel-9 packages during the actual installability.

Can you ping me during the weekend? I can try to see some better ways to do this from tmt side

[LecrisUT]

This should distinguish between epel9 and epel9-next dist-git branch. I think there could also be a complication with epel9-next being pre-installed for the former case.

[dherrerace]

If you are using Centos Stream 9 as a base, you will need both epel9 and epel9-next repos installed. The epel-next branch is not a replacement for epel9, but an extension that adds fixes for epel packages that are broken on Centos Stream (usually because of updated dependencies).

And yes, the fact is that the epel-release-latest package cannot get installed is because there is an older version of the epel-next-release package and it can't get updated from the repository, and removing it from the base image would also be a valid solution to this problem, but the purpose of this fix is to make sure to install/update the latest versions of both packages, which would override the previous state in both cases where outdated epel/epel-next packages are installed or not.

I did test the command on a container env with and without the epel-next package installed and it worked fine :)

[LecrisUT]

And yes, the fact is that the epel-release-latest package cannot get installed is because there is an older version of the epel-next-release package and it can't get updated from the repository, and removing it from the base image would also be a valid solution to this problem, but the purpose of this fix is to make sure to install/update the latest versions of both packages, which would override the previous state in both cases where outdated epel/epel-next packages are installed or not.

Ah thanks for that clarification. Indeed updating the epel seems fine in this context. My only concern is to make sure we are doing the installability test in the correct epel environment (also applies for epel10.X).

Actually I have an alternative suggestion. How about if we disable epel completely until we get to the prepare step. I.e. instead of building mini-tps for epel, build it directly for plain centos-stream. The package has no dependencies (and even if it would it would be base-system ones, not epel related).

Then in the prepare make sure that all epels are disabled (normally we shouldn't need to, but let's check it if it's there by default from the testing-farm compose), and only enable it based on PROFILE_NAME if it's possible, otherwise it might need some more coordination to pass that info along

I did test the command on a container env with and without the epel-next package installed and it worked fine :)

Could you test specifically using tmt to make sure that that doesn't introduce any contamination? The instructions were just update in the README.md on the main branch.