Pavel Raiskup wrote:
First I don't feel comfortable announcing this, I'm not happy about the situation and so I don't want to be the lightning rod :-). But I believe that we can come to acceptable Copr/Mock solution and this needs to be discussed... so here we are.
I, too, believe that we can come to an acceptable solution. Unfortunately, I do not consider the one you propose to be acceptable, at all.
I am proposing (as PR against mock upstream ATM [1]) to switch the default epel-* configuration from CentOS+EPEL to RHEL+EPEL as soon as possible (see the pull request [1]).
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). In particular:
This would bring some consequences, namely newly with epel-8* chroots,
- builds will require a valid Red Hat subscription (the no-cost variant is OK as well, though [2])
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.
- we will miss some build-time packages that Red Hat is not shipping, at least at the beginning till they are added (to RHEL CRB, or other currently unknown place).
That will definitely be a problem. It has also been a constant source of trouble for EPEL itself, and should be reason enough to switch EPEL to a more cooperative (but binary-compatible) base distro (i.e., Rocky or Alma) altogether, even in Koji, i.e., in particular, even for the official RPMs.
- cross-arch compilation can not be used, Red Hat subscriptions don't allow that (using QEMU and rpm --forcearch), [3]
That, I consider to be a field-of-use restriction and incompatible with the Free Software Definition and the Open Source Definition altogether.
(Other field-of-use restrictions probably come from the wording of the developer subscription license, e.g., I guess it is not allowed to use a RHEL developer subscription mock chroot for other purposes than building packages, is it?)
The positive thing is that the default configuration will be much closer to the official EPEL builds (because Fedora Koji EPEL builds are actually done also against RHEL).
But Koji is really the odd one out, so why not instead fix Koji to work like local mock and Copr rather than the opposite?
For the Fedora Copr builders, we already have the necessary Red Hat subscriptions in hand (will be deployed by the end of the year). So we will only loose the opportunity to build on emulated epel-8-armhfp permanently, and epel-8-s390x temporarily (as we already work on the native s390x support).
So even Copr itself is hit by the field-of-use restriction. (Now, armhfp and s390x might also be unsupported by the rebuilds altogether, but at least it would be a technical restriction and not a legal one, and the technical restriction could be fixed by anyone by just building the rebuild, or even any rebuild, for those architectures.)
Any thoughts? Feedback is needed here.
See above.
Kevin Kofler