search

rpm-software-management / mock

Mock is a tool for a reproducible build of RPM packages.
GNU General Public License v2.0
381 stars 227 forks source link

Enable CentOS 10, RHEL 10, AlmaLinux 10, Oracle Linux 10, and Circle Linux builds #1385

Closed nkadel closed 1 month ago

nkadel commented 3 months ago

CentOS 10 has been published in the upstream repos. I enabled each RHEL variant's release of version 10 with a different pull request, so they can be cherry picked as needed.

Conan-Kudo commented 3 months ago

None of these exist yet. We should not merge this.

praiskup commented 3 months ago

Agreed, we should merge once these are available - the preference is to not confuse users with non-working configs.

nkadel commented 3 months ago

The EPEL enabled CFGs do not work yet, though the centos-stream-10 configs do.

praiskup commented 3 months ago

See also the older #1383

carlwgeorge commented 1 month ago

It doesn't make any sense to add configs for distros that don't exist yet, and it doesn't make sense for adding the configs to all be in one pull request because they will be released at different times. Furthermore, as written these configs reference templates that don't exist and aren't part of the pull request, like centos-stream-10.tpl and epel-10.tpl. Finally, EPEL 10 is going to have minor versions, and needs some planning put into how we approach this in the mock configs. In my opinion, this PR should just be closed.

nkadel commented 1 month ago

"Each will be released differently" is why I submitted each file as a distinct commit, the merge can be cherry-picked as each release occurs.

EPEL is a separately complex issue, being put through a kaleidoscope of release practices by RHEL's attempts to discard point releases with the often unwelcome "stream" model, and EPEL's attempt to separately revert to a release based model. Staring at this, I'd suggest "don't mix the streams!!!", it's likely to generate complex dependency interactions, especially with tools like python modules.

I didn't like the switch to "streaming" releases, I had some colorful metaphors for just what "stream" we were being asked to drink from. But i don't see splitting the RHEL streams to provide numbered EPEL release management in mock as serving anyone. I've previously published notes on how to do so, mainly by working from the distribution media. I don't see how mock and EPEL can really wedge into doing that unless EPEL maintains its own internal point-release based repositories for RHEL, which flies in the face of Red Hat's published policies.

If that is needed...... I have old tools available for just such purposes at https://github.com/nkadel/nkadel-rsync-scripts .

Conan-Kudo commented 1 month ago

I don't think this is actionable right now, so I'm closing this and we'll incrementally handle this as Enterprise Linux 10 distributions are made available and compatible with EPEL 10.

carlwgeorge commented 1 month ago

EPEL is a separately complex issue, being put through a kaleidoscope of release practices by RHEL's attempts to discard point releases with the often unwelcome "stream" model, and EPEL's attempt to separately revert to a release based model.

This is not the place to re-litigate or complain about previous decisions by RHEL, the CentOS Board, or the EPEL Steering Committee.

But i don't see splitting the RHEL streams to provide numbered EPEL release management in mock as serving anyone.

RHEL has minor versions, CentOS Stream reflects the upcoming minor version, and EPEL 10 is going to integrate with these minor versions. mock-core-configs will reflect these facts.

nkadel commented 1 month ago

Conan, I think you're right that this is not actionable right now. I definitely wanted to get the pull request published and reviewable for examples that can be cherry-picked as the individual operating systems are enabled