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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
