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