Should the centos-stream+epel configs exist?

[hroncok]

I see that there are the following configs:

• centos-stream+epel-8-$arch
• centos-stream+epel-9-$arch

Should they even exist? IMHO they can only lead to packager confusion. Packagers that build for centos-stream should always use epel-next, not epel.

[praiskup]

I think centos-stream+epel-9 was originally epel-next-9, and centos-stream+epel-8 was just added later (to sync with the config pattern used in 9). So I agree, to me it makes sense to drop those configs.

And while on it, I'd propose to rename centos-stream+epel-next back to just epel-next. Or at least we could provide the symlinks. Because that's what officially epel-next is (cs+epel+epel-next), or?

@carlwgeorge what do you think?

[hroncok]

Or at least we could provide the symlinks.

That would be less disturbing.

[carlwgeorge]

I would prefer not renaming it to just epel-next. I think it's valuable to have consistent naming with the other EPEL configs.

I'd actually go the other way on this, let's remove the centos-stream+epel-next-$releasever-$arch configs, and ensure that the centos-stream+epel-$releasever-$arch configs include the epel-next template. My thinking is that "EPEL on CentOS Stream" means using both EPEL and EPEL Next.

[nkadel]

The new syntax is more clear. EPEL is an option for RHEL based systems, not itself an operating system, which is the first element of all the other /etc/mock/ listings. Clarity and consistency are very useful compared to shorter configuration names.

[hroncok]

The discussion seems to have ended. The configs still exist and provide a combination of cXs with plain epelX which does not actually work (for X in 8, 9).

[sincerelysaucy]

I think what we have right now is working well enough, and the ticket can close. The "centos-stream+epel-8-x86_64.cfg" and similar, epel enabled configs seem to work quite well.

[hroncok]

They might appear to work until they don't. EPEL packages are built against released RHEL, not CentOS Stream.

[sincerelysaucy]

Since RHEL is now the downstream of CentOS, which is the beta test release for RHEL, I don't expect frequent issues. The potential for that sort of issue is real, but so far I've not seen it pop up for anything in EPEL. Have you seen a single such incident in the last few years?

[hroncok]

Yes. E.g. with python3.11-rpm.

[sincerelysaucy]

Really? I personally build a while suite of stuff that uses python 3.11, not building that RPM itself, and hadn't seen any issue. Do you have a pointer to that failure somewhere?

[hroncok]

Try installing python3.11-rpm to c8s+epel mock root.

[sincerelysaucy]

I just did, it works great. I suspect you have another issue.

* mock install python3.11 -r /etc/mock/centos-stream+epel-8-x86_64.cfg 

Maybe ensure your "mock" and "mock-core-configs" are up to date, and scrub the old image?

* mock --scrub-all-r /etc/mock/centos-stream+epel-8-x86_64.cfg 

And make sure you configs haven't been locally tweaked with an error. Because I've been using python3.11 a lot for ansible and awscli builds.

[hroncok]

1. mock -r centos-stream+epel-8-x86_64 --scurb=all
2. mock -r centos-stream+epel-8-x86_64 --init
3. mock -r centos-stream+epel-8-x86_64 --install python3.11-rpm

  - nothing provides (rpm-libs(x86-64) >= 4.14.3-28 with rpm-libs(x86-64) < 4.14.3-29) needed by python3.11-rpm-4.14.3-28.1.el8.x86_64 from epel

[sincerelysaucy]

I think you have a PEBKAC moment there. Your command three should not have that "-rpm" suffix. Try this:

3. mock -r centos-stream+epel-8-x86_64 --install python3.11

[hroncok]

I don't. I want to install the python3.11-rpm package. The RPM bindings for Python 3.11

[sincerelysaucy]

Forgive my confusion, the PEBKAC was on my end, I was seeing the "python3.11 rpm" rather than the "python3.11-rpm" package. As far as why enabling epel doesn't automatically enable epel-next, I'll quote a favorite character:

  "KRONK! Why do we even have that lever!!!???"

The answer is that it's rarely needed, and enabling yet another not-yet-fully-approved software channel adds more risk to builds, especially for security sensitive software. Let's leave that as an option in the "epel-next" labeled config files, not automatically activated, it's working well.

[gotmax23]

Well… no. The only supported[^1] way to run EPEL X on CentOS Stream X is with EPEL X Next enabled alongside it. The EPEL Next–less configuration is incorrect. It might appear to be "working well" for you, but there are several packages—including widely-used ones like the KDE stack and Ansible and python3.11-rpm that @hroncok mentioned—that will fail to install with this invalid configuration.

EPEL Next is not a separate software channel that adds any more security risk than EPEL does. EPEL and EPEL Next work together and come from the same place.

"KRONK! Why do we even have that lever!!!???"

I would turn that around. Why do we have a separate configuration for CentOS Stream without EPEL Next that is known to be broken?

[^1]: Forgive me for using the word "support." EPEL is maintained by the community and does not provides capital-s support like Red Hat does for RHEL proper.

[Conan-Kudo]

They were created initially when we were setting things up in EPEL 9. It would make sense to fold the -next configuration to the baseline one and make the -next config a symlink to the main one or the other way around.

[hroncok]

I know how it happened. That's why I reported this issue back then.

Anyway, whtger it's linked there or back I don't really care, as long as the invalid combination ceases to exist.