Learn more about these different git repos.
Other Git URLs
Hello, according to the mock pull-request discussion we will have to do something about the epel-8-x86_64 chroot.
epel-8-x86_64
One of the valid points was that people expect that fedpkg mockbuild should be an easy task to do. Is getting the subscription too problematic? What is your take on this?
fedpkg mockbuild
The most likely variant is that the new epel-* configs are just RHEL+EPEL, and that we will add new configs like rocky-epel-8-x86_64, alma-, navy- (according to what our users wil need) into mock-core-configs.
epel-*
rocky-epel-8-x86_64
alma-
navy-
Would you be comfortable picking any of those -epel variants instead of the default mock -r epel-8-x86_64 for epel8 branch?
mock -r epel-8-x86_64
FYI https://pagure.io/epel/issue/133
I think there are only 2 reasonable defaults: Rocky Linux or AlmaLinux (just pick whatever of those works better in practice, it should not really matter). Anything that requires a subscription of any sort, even a free-as-in-beer one, should be a non-starter. The default EPEL config needs to just work and to be free of field-of-use restrictions, including technically enforced policy restrictions breaking use cases such as emulation. So requiring a RHEL developer subscription is not an acceptable solution. The discrepancy with the EPEL Koji and/or Copr configuration can easily be fixed by changing those, too.
Switching the default mock config is not difficult and can certainly be done. https://pagure.io/fedpkg/blob/master/f/fedpkg/__init__.py#_151
However, it should not be fedpkg maintainers deciding this. Let's wait for https://pagure.io/epel/issue/133 to be resolved at least.
Login to comment on this ticket.